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ABSTRACT 


AMDL  is  an  abstract  form  of  the  hardware  description  language  ISPS.  This  report 
presents  a  formal  definition  of  AMDL,  using  the  techniques  of  denotational  semantics  as 
developed  by  Scott  and  Strachey.  AMDL  includes  some  nonstandard  control  and  data 
structures  which  are  easily  handled  by  this  definitional  method.  This  report  assumes 
familiarity  with  descriptive  denotational  semantics. 


1.0  Introduction 


*■  Since  the  introduction  of  ISP,  {Bell  &  Newell.  1971],  the  use  of  hardware  description  languages 
(HDI.s)  has  increased  dramatically.  Used  originally  to  describe  at  the  programming  level  the 
instruction  sets  of  digital  computers,  hardware  descriptions  arc  now  being  used  in  applications 
such  as  design  automation,  emulation,  compiler  generation,  and  program  verification  —  to  name 
only  a  few.  This  surge  of  activity  has  put  the  existing  HDI.s  to  a  thorough  test,  with  each 
application  area  making  its  own  set  of  demands  on  the  languages.  One  common  demand, 
however,  is  for  a  precise  definition  of  the  HDI.s  themselves.  -i»  0^''  1  °v  f  n<  )  2^ 

—  y 

Before  we  discuss  this  problem  of  defining  a  hardware  description  language,  let  us  look  at  a  very 
small  but  very  common  example  of  its  use.  Consider  a  "push”  instruction  on  a  typical  computer 
of  the  form  PUSH  reg,  address.  A  prose  description  of  this  instruction  might  read: 

"The  PUSH  instruction  increments  the  register  reg  and  moves  the  contents  of 
the  word  pointed  to  by  address  to  the  word  pointed  to  by  the  new  value  of 
reg." 

While  this  definition  might  seem  straightforward,  there  are  a  great  number  of  possible  difficulties. 
What  if  the  registers  were  addressable  memory  locations  and  address  points  to  reg?  Is  the 
original  value  or  the  incremented  value  of  reg  stored  at  reg  +  1?  Although  it  would  be  highly 
unlikely,  what  if  the  instruction  PUSH  reg.  address  were  being  executed  out  of  rep’  Would  the 
instruction  first  be  moved  to  an  interna!  register,  or  would  the  address  field  of  the  instruction  be 
modified  during  execution  resulting  in  a  reference  to  address  +  7?  And  what  if  reg  pointed  to 
reg  -  7?  Would  the  final  value  of  reg  be  the  contents  of  address  plus  one  or  simply  the 
incremented  contents  of  reg ?  There  are. of  course,  other  clarifications  that  might  need  to  be  made 
concerning  what  constitutes  a  legal  address,  how  overflow  conditions  are  handled,  and  other  such 
matters. 

One  could  argue  that  such  relatively  minor  details  are  not  worth  considering,  for  one  should  not 
be  writing  programs  that  depend  on  the  machine's  behavior  in  these  unusual  circumstances. 
This  is  a  difficult  argument  in  that  it  assumes  that  there  could  be  an  agreement  upon  what 
constitutes  "unusual  circumstances."  One  could  also  argue  that  there  is  nothing  wrong  with  prose 
descriptions,  and  that  this  description  simply  needs  to  be  expanded.  While  it  is  certainly  true  that 
the  description  could  be  more  carefully  worded,  it  is  arguable  that  true  precision  could  be 
obtained  using  this  approach.  Furthermore,  there  is  no  mechanism  in  English  (or  any  natural 
language)  which  ensures  that  a  definition  is  complete.  It  is  sometimes  not  a  simple  matter  to 
determine  whether  a  prose  definition  has  enumerated  all  possible  situations.  Finally,  this  kind  of 
description  is  worthless  to  an  application  program  requiring  a  computer  description.  If  we  are  to 
reap  the  benefits  of  software  such  as  compiler-compilers  and  general  program  verification  sy  stems. 


we  must  provide  a  description  more  amenable  to  automatic  processing. 

In  response  to  this  need  for  descriptive  methods,  several  hardware  description  languages  have 
been  developed.  ISP  has  been  modified  into  its  present  form  ISPS  [Barbacci  et  aL  1977]  and  is 
receiving  continued  attention.  SMITH  [TRW.  1977]  was  developed  along  similar  lines  and  is  also 
being  heavily  used.  LCD  [E'angelisti  et  aL  1976]  is  yet  another  HDL  aimed  at  the  same  set  of 
descriptive  problems.  Since  this  paper  is  concerned  more  with  ISPS  than  with  the  other  two 
languages,  let  us  examine  how  it  could  be  used  to  define  the  PUSH  instruction  we  just  examined. 
Consider  the  following  segment  of  ISPS  code: 

MEM[reg]  :  =  MEM[reg]  +  7  NEXT 
MEM[MEM(reg]l  :  =  MEM  [address! 

We  assume  for  simplicity  here  that  MEM  is  the  memory  of  the  machine  and  that  the  registers  are 
in  the  lowest  memorv  addresses.  The  "•  =  "  construct  denotes  assignment  and  "[]"  denotes  array 
reference.  Upon  examining  this  definition,  we  now  can  see  that  the  register  is  incremented  before 
the  store  takes  place.  The  PUSH  instruction  need  not  have  been  defined  this  way.  however. 
Some  alternate  definitions  (wi.h  slightly  different  semantic  meanings)  are: 

temp  :  =  MEM[reg]  +  7  NEXT 
MEM[temp]  :  =  MEM[address]  NEXT 
MEM[reg]  :  -  temp+1 

temp  :  =  MEM[reg]  +  7  NEXT 
MEM[temp]  .-  -  MEM[address]  NEXT 
MEM[reg]  :  =  MEM[reg]+  7 

Although  each  of  these  differs  slightly  in  its  meaning,  it  seems  that  taken  individually,  each  is 
unambigous.  Is  our  quest  for  clarity  therefore  over?  Unfortunately,  it  is  not.  Consider  the 
following,  perfectly  legal  ISPS  code  segment  intended  to  define  the  same  PUSH  instruction: 

MEM[MEM[reg]:  =  MEM[reg]  +  1]  -  MEM[address] 

This  definition  seems  quite  precise,  but  upon  inspection  one  discovers  a  problem.  Does  reg  get 
incremented  before  the  reference  to  address  or  after?  This  question  requires  a  clear 
understanding  of  the  meaning  of  ISPS  itself.  Unfortunately.  ISPS  has  been  defined  in  English, 
just  as  the  PUSH  instruction  was.  and  we  are  faced  with  equally  difficult  problems  of  ambiguity. 
Have  we  really  made  any  progress  then? 

Yes.  we  have  made  progress.  A  HDL  is  a  suitable  mechanism  for  describing  hardware.  What  is 
needed  is  a  mechanism  for  defining  the  HDl.s  themselves  and  preferably  one  that  can  stand  by 
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itself  without  further  definition.  To  find  such  a  mechanism,  we  look  to  the  software  world  and 
find  that  this  problem  has  already  been  addressed  for  the  case  of  conventional  programming 
languages. 

There  are  several  techniques  used  in  the  formal  definition  of  programming  languages.  Four  of 
the  most  popular  methods  are  reviewed  in  [Marcotty  et  al..  1976].  One  method  not  reviewed 
(although  it  was  mentioned)  was  that  of  denotaiional  semantics,  developed  at  Oxford  University 
[Milne  &  Strachey.  1976].  Briefly,  this  method  provides  a  means  of  mapping  programs  into 
representative  mathematic  entities  or  denotations.  This  is  done  by  assigning  a  mathematic 
function  to  each  construct  in  the  language  and  applying  these  functions  to  the  program  in 
question.  We  will  examine  denotational  semantics  more  closely  at  a  later  point  in  the  text. 

But  where  does  AMDI.  fit  in?  Recall  that  one  of  the  goals  of  a  hardware  description  is  to  allow 
it  to  be  processed  by  various  application  programs.  Unfortunately,  languages  such  as  ISPS. 
SMITE  and  LCD  are  defined  in  terms  of  character  streams,  as  are  conventional  programming 
languages.  These  character  streams  would  therefore  have  to  be  parsed  by  each  of  applications 
interested  in  processing  programs  in  the  language. 

Recognizing  this  problem,  the  people  working  on  ISPS  defined  a  fully  parenthesized  format 
called  GDB  (Global  Data  Base)  [Barbacci  et  al.,  1977],  which  was  essentially  a  parse-tree 
representation  of  ISPS  programs.  This  format  relieved  the  burden  of  parsing  from  the  various 
application  programs  and  thus  was  a  big  step  forward. 

The  problem  of  formal  definition  of  ISPS  still  existed,  however.  While  the  GDB  format  was 
more  easily  processed,  it  was  no  less  ambiguous.  Furthermore,  some  people  wanted  to  be  able  to 
process  descriptions  written  in  either  ISPS  or  SMITE.  Since  the  languages  were  quite  similar,  it 
was  hoped  that  a  superset  language  could  be  defined  into  which  ISPS  and  SMITE  programs 
could  be  translated.  Finally,  there  was  a  desire  for  an  integrated  programming  environment  for  a 
FIDE  which  allowed  a  user  to  edit,  debug  and  process  his  description  without  having  to  deal  with 
a  collection  of  different  programs,  as  was  then  the  case. 

It  was  out  of  this  situation,  and  due  to  the  presence  of  the  powerful  INTERLISP  system 
[Teitelman.  1975],  that  AMDL  (Abstract  Machine  Description  Language)  was  developed.  Like 
the  GDB  format.  AMDL  is  essentially  an  "abstract"  form  of  ISPS  suitable  for  machine 
processing.  Unlike  the  GDB  format,  however,  it  is  also  suitable  for  human  use.  particularly 
within  the  INTERLISP  environment.  Each  of  the  AMDU  constructs  is  implemented  as  an 
INTERLISP  function  with  the  full  flexibility  that  such  representation  provides.  There  is  even  a 
mechanism  available  which  allows  users  to  deal  in  conversational  AMDL,  just  as  they  can  deal  in 
conversational  LISP  (CLISP).  This  and  many  other  unique  INTERLISP  features  provide  a  quite 
rich  user  environment. 
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More  importantly.  howc\er.  it  was  possible  to  formally  define  AMDL.  While  ISPS  and  SMITE 
were  under  outside  control  and  it  was  not  possible  to  impose  a  definition  on  them  from  a 
distance,  it  was  possible  to  provide  a  translation  between  them  and  AMDL.  In  fact,  this  version 
of  AMDL  is  based  almost  solely  on  ISPS  and  translations  between  the  two  languages  are 
relatively  straightforward.  In  the  future,  it  is  suspected  that  AMDL  will  be  expanded  to  include 
some  of  the  features  of  SMITE  so  that  it  will  become  more  of  a  superset  of  ISPS  than  equivalent 
to  it. 

The  purpose  of  this  report,  then,  is  to  formally  define  AMDL.  Hopefully  this  will  serve  several 
purposes.  First,  it  should  ensure  consistency  of  interpretation  of  AMDL  among  the  various 
applications  being  developed.  Second,  it  should  show  how  denotational  semantics  can  be  used  to 
successfully  define  a  complete,  nontrivial  language.  And  finally,  it  will  point  out  the  necessity 
for  formal  definitions  in  general  and  for  ISPS  and  SMITE  in  particular. 

As  with  any  formal  definition,  the  going  gets  extremely  thick  at  times.  Moreover,  unless  one  has 
been  exposed  to  denotational  semantics  in  the  past,  the  equations  will  undoubtedly  appear  quite 
forbidding.  The  definition  in  this  report  is  intended  primarily  for  AMDL.  ISPS  or  denotational 
semantics  aficionados.  Even  then,  it  is  unlikely  that  one  could  or  would  even  want  to  read  it  in 
one  sitting.  As  a  reference  for  the  definition  of  AMDL.  it  is  hoped  that  it  might  be  useful  for  a 
somewhat  larger  audience  in  resolving  individual  questions  of  interpretation. 

The  report  is  divided  into  five  sections,  the  first  being  this  introduction.  Section  2  gives  an 
introduction  to  AMDL  and  its  relationship  with  ISPS.  Section  3  discusses  the  notation  of 
denotational  semantics  as  it  is  used  here.  Section  4.  the  bulk  of  the  report,  provides  a  step-by- 
step  presentation  of  the  formal  definition  itself.  Section  5  provides  a  summary  of  issues;  it  is 
followed  by  an  append;-  containing  a  copy  of  the  entire  definition  for  reference  purposes. 
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2.0  AMDL 


As  mentioned  earlier.  AMDL  is  an  abstract  form  of  ISPS.  That  is.  it  retains  the  fundamental 
semantic  properties  of  ISPS  while  providing  a  more  convenient  representation  for  semantic 
processing.  The  representation  is  more  convenient  primarily  because  it  is  built  up  from 
structured  objects,  in  this  case  lists.  This  list  representation  is  not  identical  to  the  abstract  syntax 
originally  introduced  in  [McCarthy.  1966].  but  lends  itself  nicely  to  the  LISP  environment  in 
which  most  of  the  applications  have  been  developed. 

In  describing  the  AMDL  syntax,  we  will  be  utilizing  the  standard  LISP  output  format  for  lists. 
That  is.  lists  will  be  represented  using  enclosing  parenthesis,  with  spaces  separating  the  individual 
elements.  Text  will  be  shown  in  an  alternative  typeface,  with  AMDL  keywords  appearing  in 
boldface.  For  example,  (bits  foo  (pair  3  0))  is  an  AMDL  construct  which  is  a  list  consisting  of 
three  elements,  the  third  of  which  is  the  construct  (pair  3  0).  The  words  bits  and  pair  are 
AMDL  keywords. 

This  section  is  divided  into  two  parts:  the  first  part  gives  a  complete  introduction  to  AMDL  and 
assumes  only  that  the  reader  is  familiar  with  high-level  language  concepts  in  general:  the  second, 
directed  at  ISPS  users,  describes  the  relationship  between  AMDL  and  ISPS.  For  those  quite 
familiar  with  ISPS,  this  second  part  might  substitute  for  the  first  as  an  introduction  to  the 
language. 

2.1  Introduction  to  the  Language 

With  a  few  significant  exceptions.  AMDL  is  a  simple  ALGOL-like  programming  language.  An 
AMDL  program  is  essentially  a  parameter-less  procedure.  Procedures  are  composed  of 
declarations  and  executable  statements  (hereafter  referred  to  as  actions).  The  declarations  define 
variables  and/or  other  procedures.  The  actions  proxide  for  the  manipulation  of  values  of  the 
declared  variables  and  changes  in  the  flow  of  control  (e.g..  loops,  procedure  calls).  What  then, 
makes  the  language  unique?  It  is  the  types  of  variables  that  are  declared  and  the  way  in  which 
the  flow  of  control  is  altered  that  gives  AMDL  (and  its  definition)  its  interesting  qualities. 

2.1.1  Variables 

AMDL  programs  deal  almost  exclusively  with  the  manipulation  of  bitstrings.  A  bitstring  is  an 
indexed  sequence  of  one  or  more  bits.  For  example,  to  declare  a  bitstring  variable  foo  four  bits 
long,  numbered  left-to-right  from  3  to  0.  one  would  use  (bits  foo  (pair  3  0)).  To  declare  the 
reverse  ordering  of  bitnames.  one  would  exchange  the  arguments  to  the  pair  expression,  as  in 
(bits  fool  (pair  0  3)).  Variables  consisting  of  only  one  bit  can  be  declared  with  a  shorthand 
notation  which  omits  the  necessity  for  the  pair  expression.  To  declare  a  bitstring  consisting  of 
one  bit  numbered  5.  one  would  use  (bits  foo2  5).  The  bit  numbers  (and  hence  the  arguments 
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to  the  pair  expression)  must  be  nonnegative.  The  last  element  in  the  bits  form  is  known  as  a 
structure,  in  that  it  describes  the  structure  of  the  bitstring. 

Variables  which  are  arrays  of  bitstrings  may  also  be  declared.  The  mechanism  and  rules  for 
numbering  the  elements  or  words  of  the  array  are  similar  to  those  for  numbering  the  bits  in  a 
bitstring.  For  instance,  to  declare  an  array  foobar  of  15  elements  numbered  in  ascending  order 
beginning  with  100.  one  would  use: 

(bits  (words  foobar  (pair  100  114))  (pair  3  0)) 

Note  that  this  is  similar  to  the  declaration  for  foo  above,  except  that  instead  of  having  just  foobar 
as  the  second  element  in  the  bits  expression,  we  have  (words  foobar  (pair  100  114)).  where 
the  third  element  in  the  words  expression  is  a  structure  describing  the  numbering  of  the  array. 
The  words  expression  always  occurs  inside  of  the  bits  expression,  if  both  are  present.  The 
same  convention  of  allowing  a  single  number  to  denote  a  pair  of  identical  numbers  is  used,  so 
that  (bits  (words  foobarl  100)  0)  would  declare  an  array  of  one  word  named  100,  containing 
one  bit  named  0. 

To  reference  a  variable,  one  uses  almost  identical  forms  as  those  used  to  declare  a  variable.  For 
instance,  to  access  the  middle  two  bits  of  the  four-bit  variable  foo  discussed  above,  one  would  use 
(bits  foo  (pair  2  1)).  The  leftmost  (high-order)  bit  could  be  accessed  by  (bits  foo  3).  To  refer 
to  the  entire  bitstring,  one  could  use  (bits  foo  (pair  3  0))  or  just  simply  foo.  which  implies 
reference  to  the  full  variable.  As  might  be  expected,  access  to  arrays  uses  the  words  form.  To 
access  the  second  word  of  the  array  foobar  above,  one  would  use  (words  foobar  101).  Only 
one  word  can  be  referenced  at  a  time,  therefore,  pair  expressions  are  not  allowed  in  the  words 
form  in  this  case.  A  sub-bitstring  of  a  word  can  be  referenced,  however,  as  with  (bits  (words 
foobar  101)  (pair  1  0)j  which  is  referring  to  the  two  low-order  bits  of  the  second  word  of 
foobar. 

There  is  another  important  difference  between  the  forms  used  for  accessing  variables  and 
declaring  variables.  When  declaring  variables,  only  constants  are  allowed  in  naming  the  words 
and  bits.  In  accessing  \ariables.  however,  expressions  can  be  used.  We  will  examine  expressions 
soon,  but  for  now  it  is  sufficient  to  say  that  an  expression  is  a  form  which  is  evaluated  at  run¬ 
time  to  produce  a  nonnegative  value.  This  value  is  then  used  in  place  of  a  constant  for  indexing 
into  the  variable.  Fxpressions  can  occur  in  two  places  in  an  access.  First  of  all.  they  can  be  used 
in  a  words  form  to  reference  a  word  in  an  array,  as  in  (words  foobar  exp).  In  the  above 
example,  exp  must  have  a  value  lying  between  100  and  114.  Secondly,  an  expression  can  occur 
in  an  access  to  a  specific  bit  of  a  bitstring,  as  in  (bits  foo  exp).  In  this  example,  exp  must  have 
a  value  between  0  and  3.  An  expression  cannot  occur  within  a  pair  form  in  this  context.  For 
instance,  (bits  foo  (pair  exp  1))  would  not  be  legal,  even  if  exp  always  resulted  in  a  value 
within  the  legal  range.  I  his  restriction  is  imposed  so  that  the  length  (in  bits)  of  any  variable 


access  cannot  vary  at  run  time.  This  third  element  in  the  bits  access  form  is  known  as  a 
si  rue  lure  reference. 

2.1.2  Expressions 

We  just  mentioned  that  an  expression  is  a  form  that  is  evaluated  at  run-time  to  produce  a  non- 
negative  value.  Actually,  it  produces  a  bitstring,  which  can  be  interpreted  in  any  way  desired. 
One  of  these  interpretations  is  as  a  base-two.  nonnegative  integer,  producing  the  value  referred  to 
above.  We  also  speak  of  the  length  of  an  expression  in  bits  and  will  see  how.  as  with  variable 
references,  the  length  of  an  expression  remains  constant  at  run-time.  Because  a  value  and  length 
uniquely  determines  a  bitstring,  one  can  think  of  an  expression  as  producing  a  < value,  length > 
pair,  rather  than  a  bitstring,  when  it  is  convenient  to  do  so. 

2. 1.2. 1  Constants 

A  constant  is  a  bitstring  whose  value  docs  not  change  at  run  time.  The  nonnegative  integers  we 
saw  earlier  in  variable  declarations  and  v  ariable  accesses  are  actually  a  subclass  of  constant.  They 
have  an  explicit  length  equal  to  one  greater  than  the  number  of  bits  required  to  represent  them  in 
base  two.  For  instance,  the  integer  2  would  have  a  length  of  3.  the  integer  5  would  have  a 
length  of  4,  and  so  on.  There  are  three  other,  nearly  identical,  types  of  constants  whose  forms 
are 

(hconst  val  ten),  (bconst  vat  ten)  and  (oconst  val  ten) 

where  val  and  len  are  nonnegative  integers  giving  the  value  and  length  of  a  constant  bitstring. 
The  reason  for  the  three  equivalent  forms  of  constant  is  not  easily  explained  in  this  context,  but  is 
not  important  for  our  purposes.  Any  of  these  forms,  though,  could  appear  within  a  stivcture  or 
structure  reference  in  place  of  a  simple,  nonnegative  integer.  The  length  component  is  then  just 
ignored. 

2. 1.2. 2  \  ariable  R  eferences 

We  have  already  examined  the  variable  reference.  A  variable  reference  is  a  legal  expression. 

2. 1.2. 3  Data  Operator  Expressions 

There  are  a  large  number  of  data  operators  defined  in  AMDL.  Most  of  these  are  binary  operators 
and  occur  in  expressions  of  the  form  ( operator  ex  pi  exp2),  where  operator  is  some  AMDL 
keyword.  In  addition,  there  are  a  few  unary  operators,  used  in  expressions  of  the  form  (operator 
exp).  The  data  operators  are  further  discriminated  by  mode  into  unsigned  and  two's  complement 
operators,  corresponding  to  the  ways  in  which  the  operators  interpret  their  arguments.  The 
keywords  for  unsigned  operators  each  begin  with  us  while  the  keywords  for  two's  complement 


operators  each  begin  with  tc.  lhe  unsigned  operators  interpret  their  arguments  as  either  boolean 
strings  or  as  unsigned  representations  of  integers. 

Hxamples  of  binar>  unsigned  operators  which  interpret  their  arguments  as  logical  bitstrings  are 
usor.  usand.  usxor  and  useqv  which  implement  the  basic  boolean  functions  on  a  bitstring 
basis.  Shift  operators,  both  right  and  left  and  with  various  "fill"  bits,  are  performed  by  ussrO. 
ussrl.  ussrr.  ussrd.  usslO.  ussll.  usslr  and  ussld.  The  concatenation  of  two  bitstrings  is 
achieved  by  the  usconc  operator.  In  addition,  there  is  a  set  of  binary  operators  w'hich  occur  in 
both  unsigned  and  two  s  complement  versions.  The  unsigned  versions  of  these  are  as  follows: 
usplus.  usdifference.  ustimes  usquotient.  usremainder.  useql.  usneq.  uslss.  usgtr. 
usleq,  usgeq.  and  ustst.  The  two's  complement  versions  have  identical  names,  except  with 
"tc"  substituted  for  "us".  Each  of  these  operators  has  particular  rules  for  dealing  with  operands 
of  differing  lengths  which  we  will  not  discuss  here.  The  rules  will  be  given  explicitly,  however,  in 
the  formal  definition  itself. 

Unary  operators  are  usnot,  which  gives  the  logical  complement  of  its  operand,  and  teminus. 
which  gives  the  two's  complement  negation  of  its  operand. 

2. 1.2. 4  Substring  expression 

The  form  (ussub  exp  structure)  is  available  in  order  to  refer  to  a  substring  of  an  arbritary 
expression.  In  this  case,  the  numbering  of  the  bits  in  the  expression  exp  is  implicitly  taken  to  be 
ascending,  right-to-left  beginning  w  ith  0.  In  other  words,  the  form  (ussub  exp  (pair  1  0))  will 
always  return  the  right  two  bits  of  the  expression:  if  the  bit  substring  referenced  extends  beyond 
the  length  of  the  expression,  then  zero  padding  on  the  left  is  assumed. 

2. 1.2.5  Assignment 

Assignment  in  AVIDL  is  performed  using  one  of  two  transfer  operators.  The  general  form  of  an 
assignment  is  ( transfer-op  ( vart  var2  ...  varN)  exp).  where  the  bitstring  returned  by  the 
expression  exp  is  assigned  to  the  concatenation  of  the  variables  varl  var2  ...  varN.  That  is.  the 
vari  can  be  viewed  as  destination  receptacles  which  are  lined  up  in  sequence.  The  bits  of  the 
source  expression  exp  are  then  deposited  into  the  receptacles,  one  bit  at  a  time,  beginning  with 
the  rightmost  bit  of  the  source  and  the  rightmost  bit  of  the  destination.  The  transfer  operators 
usset  and  teset  correspond  to  the  two  modes  of  arithmetic  interpretation.  They  differ  in  the 
way  in  which  they  extend  the  source  value  in  the  case  of  unequal  source  and  destination  lengths. 

2. 1.2.6  Procedure  Calls 

Procedure  calls  arc  performed  with  the  form  (call  variable-reference  expl  exp2  ...  expN)  The 
expressions  are  the  actual  parameters  to  the  procedure  being  called.  They  are  evaluated  from  left 
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to  right  and  passed  by  value  to  the  procedure.  I  here  is  no  wav  to  pass  parameters  by  reference 
and  no  way  to  store  values  into  actual  parameters  upon  return.  The  number  of  actual  parameters 
must  match  the  number  of  formal  parameters.  Procedures  cannot  be  called  recursively. 

The  fact  that  the  second  element  in  the  call  form  is  a  variable  reference  deserves  comment.  In 
AMDL,  identifiers  can  denote  variables,  procedures,  or  both.  A  procedure  call  can  be  used  as  an 
expression  when  it  refers  to  an  identifier  representing  both  a  procedure  and  a  variable.  The 
semantics  of  the  call  is  as  follows: 

1.  Evaluate  the  parameters. 

2.  Call  the  procedure  associated  with  the  identifier  contained  in  the 
variable  reference. 

3.  After  the  procedure  returns,  evaluate  the  variable  reference  to  obtain 

a  bitstring  which  is  the  expression  value. 

We  will  see  later  that  there  is  no  special  status  for  variables  whose  identifier  is  also  associated 

with  a  procedure.  That  is.  they  can  be  accessed  in  the  same  manner  as  variables  which  do  not 

have  a  procedure  associated  with  them.  Furthermore,  they  are  not  implicitly  stored  into  upon 
return  from  the  associated  procedure.  This  would  allow  for  some  rather  unusual  programming 
practices,  such  as  two  procedures  storing  into  each  other's  associated  variable. 

2.1.3  Actions 

Actions  are  the  next  major  AMDL  construct.  Two  forms  we  have  already  examined  as 

expressions,  the  assignment  and  procedure  call,  are  legal  actions  as  well.  The  remaining  actions 
are  described  below. 

2. 1.3. 1  Conditional  Action 

A  simple  conditional  statement  of  the  form  (cond  (exp  action))  is  provided.  Its  semantics  are 
straightforward.  If  the  result  of  evaluating  the  expression  produces  a  nonzero  value,  the  action  is 
cv  aluated. 

2. 1.3. 2  Sequences  of  actions 

The  form  (seq  aett  act2  ...  actN)  is  used  for  sequencing  two  or  more  actions.  The  semantics  is 
to  perform  the  actions  in  order  from  left  to  right.  There  is  also  a  form,  (par  aett  act2  ...  actN). 
for  specifying  parallel  execution  of  actions.  The  semantics  of  this  form  is  currently  identical  to 
the  semantics  of  the  seq  form,  but  will  be  generalized  at  a  later  date.  Finally,  there  is  a 
construct  (repeat  action )  which  repeats  the  execution  of  a  specified  action  an  indefinite  number 
of  times.  Note  that  the  operation  of  these  sequencing  mechanisms  is  subject  to  alteration  by  one 
of  the  following  control  actions. 
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2. 1.3.3  Labels  and  control  actions 


An  action,  usually  itself  a  sequence  of  actions,  can  be  labelled  for  subsequent  reference  within  the 
bod>  of  the  action.  A  label  is  attached  with  the  form  (label  identifier  action).  This  label  is  in 
effect  at  all  points  within  the  action  unless  superseded  by  another  label  with  the  same  name. 

There  are  three  control  actions  which  can  reference  labels.  The  first  is  of  the  form  (leave 
identifier).  Execution  of  this  action  will  cause  control  to  be  passed  to  the  first  action  following 
the  action  labelled  with  the  given  name.  If  no  such  action  exists  within  the  current  procedure, 
then  the  identifier  must  refer  to  a  procedure  of  that  name.  The  procedures  which  can  be  referred 
to  are  those  that  are  statically  accessible  (using  the  same  conventions  as  for  variable  access)  and 
activated.  If  both  of  these  criteria  are  met.  then  the  semantics  of  the  leave  is  to  return  from  the 
specified  procedure. 

The  second  control  action  is  of  the  form  (restart  identifier).  Like  the  leave  action,  it  refers  to 
a  label,  if  present.  In  this  case,  the  semantics  are  to  restart  the  execution  of  the  action  associated 
with  the  label.  In  case  no  label  of  the  given  name  is  present,  the  same  rules  for  referencing 
procedures  apply  as  for  the  leave  action.  However,  instead  of  returning  from  the  referenced 
procedure,  the  procedure  is  restarted.  This  restarting  process  can  be  thought  of  as  discarding  any' 
procedure  activations  between  the  current  procedure  and  the  referenced  procedure,  and  beginning 
execution  at  the  first  action  in  the  referenced  procedure. 

The  third  control  action  is  the  resume  action,  of  the  form  (resume  identifier).  This  action  can 
only  refer  to  a  procedure  and  specifically  not  to  the  current  procedure.  That  is,  it  is  a  mechanism 
for  resuming  execution  of  a  procedure  other  than  the  current  one.  Its  semantics  can  be  thought 
of  in  terms  of  the  leave  action.  Performing  a  resume  of  a  procedure  is  identical  to  performing 
a  leave  of  the  procedure  which  that  procedure  last  called.  For  instance,  if  procedure  A  calls 
procedure  B.  and  procedure  B  calls  procedure  C.  then  a  resume  of  procedure  A  would  have  the 
same  effect  as  a  leave  of  procedure  B.  Likewise,  (resume  B)  would  produce  the  same  results 
as  (leave  C).  at  this  point. 

2. 1.3.4  Decode  action 

The  decode  action  is  similar  to  a  select  or  case  statement  in  other  programming  languages.  It 
has  the  form 

(decode  exp 

{selector  action  1) 

( selector  actio n2) 


( selector  actionN )) 
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where  the  successive  selectors  are  compared  to  the  value  of  the  expression  until  one  of  them 
"succeeds."  When  that  occurs,  the  associated  action  is  executed.  The  selector  can  take  one  of  the 
following  three  forms: 

otherwise 

structure 

(structurel  structure2  ...  structureN) 

The  structures  referred  to  are  like  those  discussed  in  the  section  on  variables.  That  is.  a  structure 
is  either  a  constant  or  a  pair  form  with  constant  arguments.  The  otherwise  selector  always 
succeeds  and  would  reasonably  only  appear  as  the  last  selector,  if  present  at  all.  The  second  form 
specifies  a  single  structure.  If  the  value  of  the  expression  falls  w  ithin  the  bounds  specified  by  that 
structure,  then  the  selector  succeeds.  (In  the  case  where  the  selector  is  a  single  constant,  then  the 
value  of  the  expression  must  equal  that  constant.)  The  third  form  is  a  means  for  specifying  a  list 
of  structures  such  that  if  the  value  of  the  expression  falls  within  the  bounds  specified  by  any  of 
the  structures,  the  selector  succeeds. 

2.1.4  Declarations 

The  last  group  of  AMDL  constructs  are  the  declarations.  We  have  already  examined  simple 
variable  declarations  (Section  2.1.1).  The  other  two  types  of  declarations  are  the  procedure 
declaration  and  the  overlay  declaration. 

2. 1.4.1  Procedures 

The  form  of  a  procedure  declaration  is  as  follows: 

(proc  var  (varl  var2  ...  varN)  dec 7  dec2  ...  decN  action ) 

where  the  "var" s  are  variable  declarations  like  those  discussed  in  the  first  section.  The  specific 
term  var  above  (the  second  element  in  the  form)  has  a  dual  purpose.  First  of  all.  the  identifier 
contained  within  var  is  the  identifier  that  is  associated  with  the  procedure  definition.  Secondly, 
however,  if  var  specifies  a  structure  (that  is.  if  it  is  a  bits  form)  then  this  serves  as  a  variable 
declaration  as  well.  This  is  the  mechanism  whereby  an  identifier  can  be  the  name  of  both  a 
variable  and  a  procedure. 

The  list  (varl  var2  ...  varN)  specifies  the  formal  parameters  of  the  procedure.  Each  of  the  vari 
in  the  list  must  be  a  non-array  variable  declaration.  When  this  procedure  is  called,  the  values  of 
the  actual  parameters  are  assigned  to  the  formal  arguments. 

The  declarations  dec  7  dec2  ...  decN  are  optional  and  specify  declarations  which  are  local  to  this 
procedure.  All  variables  are  treated  statical I)  for  purposes  of  allocation.  They  are  not  initialized 
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at  procedure  entry  and  retain  their  value  from  one  call  to  the  next. 


The  action  action  in  the  declaration  gets  executed  when  the  procedure  is  invoked. 

2. 1.4. 2  Overlays 

The  overlay  construct  is  a  method  of  associating  new  names  with  previously  defined  variables.  Its 
general  form  is  (over  var  ( varl  var2  ...  varN)).  Very  briefly,  the  semantics  of  this  declaration  is 
to  indicate  that  ensuing  references  to  var  are  to  be  treated  as  references  to  the  concatenation  of 
varl  var2  ...  varN.  even  in  the  case  of  an  assignment.  The  full  semantics  of  this  declaration  is 
quite  complicated.  Rather  than  enter  into  a  full  explanation  here,  we  will  give  a  few  simple 
examples.  Consider  the  following  declarations: 

(bits  acc  (pair  7  0)) 

(bits  ext  (pair  7  0)) 

(over  (bits  double  (pair  15  0))  (ext  acc)) 

These  declarations  can  be  viewed  as  establishing  two  registers,  acc  and  ext,  and  then  defining 
double  as  the  concatenation  of  those  two  registers.  For  example,  the  following  pairs  of 

references  would  then  be  equivalent. 

ext  (bits  double  (pair  15  8)) 

(bits  acc  (pair  2  0))  (bits  double  (pair  2  0)) 

(usconc  (bits  ext  0)  (bits  acc  7))  (bits  double  (pair  8  7)) 

Another  set  of  declarations  equivalent  to  those  above  is  as  follows: 

(bits  double  (pair  15  0)) 

(over  (bits  acc  (pair  7  0))  ((bits  double  (pair  7  0)))) 

(over  (bits  ext  (pair  7  0))  ((bits  double  (pair  15  8)))) 

Overlays  can  also  be  used  in  conjunction  with  arrays.  We  won't  go  into  those  examples  here,  but 
they  are  discussed  thoroughly  in  the  formal  definition. 

2.2  Relation  to  ISPS 

The  relation  between  ISPS  and  AMDL  is  very  close  to  the  relationship  between  a  language  and 
the  domain  of  its  parse  trees.  That  is.  the  translation  between  ISPS  and  AMDL  is  essentially  a 
syntactic  transformation.  There  arc  some  exceptions  to  this,  however,  and  they  will  be  identified 
in  the  following  paragraphs. 

ISPS,  like  most  concrete  languages,  utilizes  various  special  characters  to  delimit  the  various 
syntactic  entities.  Sequential  actions,  for  instance,  are  separated  by  the  keyword  "NEXT'  while 
parallel  actions  are  separated  by  semicolons.  Square  brackets  arc  used  for  array  references  while 
angle  brackets  are  used  for  bit  references.  Labels  are  distinguished  by  the  ”:  =  "  that  follows 
them,  and  so  on.  In  AMDL.  there  is  one  basic  sy  ntactic  form,  the  list.  The  first  element  of  this 
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list  is  used,  if  necessary.  as  a  keyword  to  distinguish  the  construct  represented  by  the  list.  For 
example,  the  ISPS  phrase  foo[arg1]<arg2>  would  be  represented  in  AMDL  as  (bits  (words  foo 
argl)  arg2).  The  rules  for  this  conversion,  though,  are  quite  straightforward. as  will  be  shown. 

litis  section  is  organized  roughly  along  the  lines  of  the  ISPS  reference  manual.  Each  ISPS 
language  construct  will  be  discussed  in  turn  and  related  to  its  corresponding  AMDL  construct,  if 
such  a  construct  exists. 

2.2.1  Character  Set.  Identifiers  and  Constants 

All  of  the  special  characters  required  for  syntactical  purposes  in  ISPS  are  absent  from  AMDL. 
The  rules  for  constructing  identifiers  are  unchanged,  though,  except  that  AMDL  distinguishes 
between  upper  and  lower  case  letters. 

Representation  of  constants  is  done  somewhat  differently  in  AMDL.  To  review,  there  are  four 
different  types  of  ISPS  constant  expressions:  decimal,  binary,  octal  and  hexadecimal.  Decimal 
constants  are  represented  in  AMDL  as  they  are  in  ISPS,  by  the  decimal  representation  of  an 

integer.  The  conventions  for  "length"  are  the  same:  the  constant  is  understood  to  be  one  bit 

longer  than  the  number  of  bits  needed  to  represent  it.  The  difference  comes  in  the  handling  of 
the  remaining  types  of  constants.  Rather  than  using  special  characters  to  denote  the  base  of  the 
constant  and  then  interpreting  the  following  numeric  term  as  a  number  in  that  base.  AMDL  uses 
the  forms  (bconst  value  length),  (oconst  value  length)  and  (hconst  value  length)  to 
represent  binary,  octal  and  hexadecimal  constants,  respectively.  However,  the  keywords  bconst. 
oconst  and  hconst  function  only  as  comments.  In  each  case,  the  terms  value  and  length  arc 
decimal  numerals  giving  the  unsigned  value  of  the  constant  and  its  length  in  bits,  respectively. 
The  distinctive  keywords  are  only  utilized  when  displaying  the  constants  (e.g.;in  a  pretty  print). 

There  are  no  comments,  aliases  or  text  strings  in  AMDL.  Name  pairs,  represented  with  an 

intervening  colon  in  ISPS,  are  represented  with  the  form  (pair  exp  exp). 

2.2.2  ISPS  Descriptions 

In  ISPS,  one  deals  with  entity -heads  which  may  or  may  not  have  a  formal  connection  set  or 
formal  structure  set.  Associated  with  these  entity-heads  is  an  entity -body,  which  may  be  either 
null,  a  section  list,  a  behavioral  expression  or  a  entity -formal-structure-map.  There  is  a  large 
number  of  syntactic  combinations  that  can  be  made  from  these  heads  and  bodies,  many  of  which 
are  meaningless  (such  as  a  entity-head  with  a  formal  connection  set  and  a  null  body).  AMDL 
retains  the  intended  power  of  this  mechanism  while  greatly  simplifying  the  syntax. 

There  are  three  types  of  declarations  in  AMDL:  a  procedure  declaration,  a  variable  declaration 
and  an  overlay  declaration.  The  variable  declaration  corresponds  to  an  entity-head  with  a 
structure,  but  no  formal  connection  set  and  a  null  entity-body.  Replacing  the  square  brackets. 
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however.  is  the  A\1DL  fonn  words.  For  instance.  foo[5]  would  be  (words  foo  5)  in  AMDL. 
In  a  similar  fashion,  the  bits  form  replaces  the  angle  brackets.  The  ISPS  term  foo<7>  would  be 
(bits  foo  7)  in  AMDL.  The  combined  case  of  foo[5]<7>  would  be  represented  as  (bits  (words 
foo  5)  7).  with  the  bits  form  always  surrounding  the  words  form.  The  use  of  name  pairs  in 
this  context  is  straightforward.  For  instance.  foo[5]<7:0>  would  be  (bits  (words  foo  5)  (pair  7 
0)). 

The  procedure  declaration  provides  the  context  for  the  other  types  of  declarations.  Its  syntax, 
which  is  similar  to  that  in  most  programming  languages,  is: 

(proc  var  ( varl  var2  ...  varN)  dec 7  dec2  ...  decN  action) 

The  second  element  of  the  list  corresponds  to  the  ISPS  entity-head.  The  third  element  is  the 
(optional)  list  of  formal  parameters.  Following  that  are  Kero  or  more  local  declarations  and 
finally  the  required  action  for  the  procedure.  The  formal  parameters  are  treated  as  local  variable 
declarations  and  may  not  be  array  variables.  Upon  procedure  activation,  parameters  are  always 
passed  by  value. 

This  procedure  declaration  mechanism  provides  the  ability  to  utilize  a  single  identifier  for 
representing  a  variable  and  a  procedure.  This  ability  corresponds  to  the  ISPS  feature  of  allowing 
separate  specification  of  structure  and  behavior.  In  a  manner  similar  to  ISPS,  if  the  var 
component  of  the  declaration  is  just  an  identifier,  then  no  variable  declaration  takes  place  (the 
entity  has  no  structure,  in  ISPS  terms).  A  call  to  this  procedure  could  never  be  used  in  an 
expression  in  that  it  wouldn't  "return"  a  value.  However,  if  var  is  a  variable  form  (i.e..  its 
keyword  is  bits),  then  it  is  treated  as  a  declaration.  As  in  ISPS,  the  identifier  has  the  status  of  a 
bona  fide  variable  and  can  then  be  accessed  independently  from  its  associate  procedure. 

The  AMDL  overlay  corresponds  to  the  ISPS  entity-head  with  a  E-FS-Map.  It  is  a  means  of 
mapping  a  new  variable  onto  one  or  more  previously  defined  variables.  The  syntax  is  (over  var 
( varl  var2  ...  varN)).  where  the  var s  are  subject  to  rules  similar  to  those  for  ISPS  in  the  same 
situation. 

2.2.3  Behavior  Expressions 

'Hie  corollary  to  the  ISPS  behavioral  expression  is  simply  the  A.VIDL  procedure  action.  AMDL 
retains  the  word  action,  coined  by  ISPS,  in  place  of  statement,  but  there  need  be  no  distinction. 
The  ISPS  description  of  an  action  as  "...  the  sequence  of  transformations  and  transfer  of  values 
stored  in  carriers  ..."  could  as  easily  be  applied  to  an  executable  statement  occurring  in  any 
programming  languag  It  involves  variables,  constants,  loops,  procedure  calls  and  other  such 
common  things. 

ITie  mapping  from  ISPS  actions  to  AMDL  actions  is  again  purely  syntactic.  Sequential  actions 
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are  represented  by  (seq  actl  act 2  ...  actN).  Parallel  actions  use  the  same  form  except  with  par 
substituted  for  seq  There  arc  no  "named  blocks"  in  AMDL.  An  "if’  statement  is  represented 
b>  (cond  (exp  act)).  The  control  operations  take  the  form  (repeat  act),  (leave  id),  (restart 
id)  and  (resume  id).  Procedure  calls  are  accomplished  by  the  form  (call  id  exp 7  exp2  ... 
expN).  where  id  is  the  name  of  the  procedure  ap.d  the  exps  are  the  actual  parameters  to  the 
procedure. 

The  decode  statement  is  derived  directly  from  the  ISPS  syntax.  The  general  format  is: 

(decode  exp 

(selector  action 7) 

(selector  action2) 


(selector  actionN)) 

where  selector  is  either  the  keyword  otherwise,  a  name  pair,  a  constant,  or  a  list  of  name 
pairs  and  constants.  The  semantics  of  these  selectors  is  identical  to  that  of  ISPS. 

2.2.4  Carrier  Expressions 

ISPS  provides  a  hierarchical  definition  of  carrier  expressions  which  implies  a  specific  precedence 
for  expression  evaluation.  No  such  hierarchy  is  required  in  AMDL.  where  all  such  operations  are 
specified  in  prefix  form.  Operations  are  either  binary  operations  or  unary  operations,  with  the 
forms  (binary-op  expl  exp2)  and  (unary-op  exp),  respectively. 

A  subset  of  the  operations  provided  in  ISPS  are  provided  in  AMDL.  The  one's  complement  and 
signed  magnitude  modes  of  arithmetic  have  been  omitted,  leaving  only  unsigned  and  two's 
complement.  Furthermore,  qualifiers  are  not  supported  for  the  purposes  of  specifying  the  current 
mode.  All  operations  carry  a  specific  arithmetic  in  their  name.  Specifically,  all  two's  complement 
operations  begin  with  the  two  letters  tc.  and  all  unsigned  operations  with  the  letters  us.  Those 
operations  which  behave  identically  in  all  ISPS  modes  contain  the  us  prefix  by  default.  A  table 
of  the  ISPS  operations  and  their  AMDL  counterparts  is  given  below. 

ISPS  Operator  AMDL  Keyword(s) 


+ 

usplus,  tcplus 

-  (binary) 

usdifference.  tcdifference 

• 

ustimes,  tetimes 

/ 

usquotient.  tequotient 

MOD 

usmod.  temod 

eql 

useql,  tceql 

neq 

usneq  teneq 

Iss 

uslss.  tclss 
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1 >  4Vr  ■ 
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leq 

usleq.  tcleq 

Qtr 

usgtr.  tegtr 

geq 

usgeq.  tegeq 

srO 

ussrO 

srl 

ussrl 

srr 

ussrr 

srd 

ussrd 

slO 

usslO 

sll 

ussll 

sir 

usslr 

sid 

ussld 

or 

usor 

and 

usand 

eqv 

useqv 

xor 

usxor 

@ 

usconc 

not 

usnot 

-  (unary) 

teminus 

In  ISPS,  there  is  both  a  regular  transfer  operation  and  a  sign-extend  transfer  operation,  the  latter 
being  available  in  the  various  arithmetic  modes.  In  keeping  with  the  decision  regarding  data 
operations.  AMDL  supports  two's  complement  and  unsigned  sign-extended  transfer  operations. 
However,  it  was  noticed  that  the  regular  transfer  operation  was  identical  to  the  unsigned  sign- 
extended  transfer  operation.  So  the  need  for  the  special  form  for  a  regular  transfer  operation  was 
lost.  The  form  of  a  transfer  is  then  ( transfer-op  (varl  var2  ...  varN)  exp),  where  transfer-op  is 
either  usset  or  tcset.  I  Me  list  of  destination  variables  [varl  var2  ...  varN)  would  correspond  to 
the  term  varl  @var2@...@varN  in  ISPS. 

An  ISPS  carrier  access  and/or  activation  corresponds  to  an  AMDL  variable  access  or  procedure 
call.  To  access  an  AMDL  variable,  one  simply  uses  the  standard  bits  and  words  notation.  To 
call  a  procedure,  one  uses  a  form  similar  to  procedure  call  form  used  in  an  action,  namely  (call 
var-ref  expl  exp2  ...  expN).  The  difference  is  that  instead  of  a  simple  identifier  as  the  second 
element  in  the  form,  a  v  ariable  reference  appears.  This  prov  ides  the  mechanism  of  joint  access 
and  activation  supported  in  ISPS. 

2.2.5  Qualifiers  and  Identifier  Sequences 

There  are  no  qualifiers  or  identifier  sequences  in  AMDL. 
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2.2.6  ISPS  Definitions 


There  are  no  macro,  define  or  require  statements  in  AM DL 

2.2.7  PredeclareJ  Emilies 

There  are  no  predeclared  entities  in  AMDL. 
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3.0  dotation 


As  mentioned  earlier,  this  report  assumes  that  the  reader  is  familiar  with  the  descriptive 
techniques  of  denotational  semantics.  For  those  w  ho  are  not.  several  discussions  of  the  technique 
of  denotational  semantics  can  be  found  in  the  literature.  Of  these.  [Gordon.  78)  gives  an 
exceptional!)  clear  introduction  to  the  subject.  This  section  merely  reviews  the  notational 
conventions  used  in  the  report.  Whenever  possible,  the  conventions  used  are  those  of  Milne  and 
Strachev  as  found  in  [Milne  &  Strachey.  1976],  It  was  felt  that,  despite  its  shortcomings,  it  was 
better  to  use  the  standard  convention  than  introduce  a  variant. 

3.1  Syntax 

The  AMDL  syntax  is  specified  by  a  list  of  syntactic  domains  and  a  set  of  BNF-like  equations 
giving  the  definition  of  those  domains.  The  list  of  domains  is  of  the  following  form: 

A:  Dec  Declarations 

which  states  that  A  w  ill  be  used  to  specify  an  element  of  the  domain  Dec  which  is  the  domain  of 
AMDL  Declarations.  Capital  Greek  letters  (such  as  A)  are  always  used  to  represent  an  element 
from  a  sy  ntactic  domain.  An  attempt  was  made  to  match  the  Greek  letters  w  ith  the  domains  in  a 
meaningful  way.  but  this  was  not  always  possible.  The  use  of  single  Greek  letters  to  denote 
sy  ntactic  elements  is  one  of  the  conventions  of  denotational  semantics  which  may  be  worth  re¬ 
examining. 

An  example  should  serve  to  explain  the  meaning  of  the  syntactic  equations.  Again,  considering 
the  domain  Dec.  we  have: 

A  ::=  (proc  nQ  (rij  n2  ...  nn>0)  Aj  A2  ...  Am>0  A)  | 

lover  n0  ( n j  n2  nn)>  | 
n 

The  notation  "  is  used  to  define  the  set  represented  by  the  element  on  the  left  by  the 
expression  on  the  right.  The  vertical  bar  "I"  is  used  as  an  alternation  symbol.  From  this  example 
then,  we  see  that  a  declaration  A  can  be  any  of  the  three  forms  (proc  ...).  (over  ...)  or  n. 
Boldface  type  is  used  to  denote  AMDL  keywords,  such  as  proc  or  over.  The  parentheses  can 
be  viewed  in  either  of  two  ways.  Since  AMDL  programs  are  actually  list-structures,  the 
parenthesis  can  be  thought  of  as  denoting  that  list  structure.  For  instance,  (over  FIq  ( n |  n-> 
nn»  is  a  list  containing  three  elements,  the  last  of  which  is  a  list  as  well.  Alternately,  the  syntax 
can  be  thought  of  as  representing  the  way  in  which  an  AMDL  program  would  be  printed.  In  this 
case,  the  parentheses  would  be  viewed  as  (reserved)  symbols  of  the  language.  In  LISP  terms,  it  is 
the  question  of  whether  to  model  the  lists  themselves  or  their  prim- names.  The  distinction  does 
not  affect  the  semantic  definition. 

Subscripts  are  used  to  distinguish  between  individual  occurrences  of  an  element  from  the  same 
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syntactic  domain.  Ellipses  are  used,  as  in  lover  n0  ( FI  j  fh  n n )).  to  represent  a  sequence  of 
items.  The  members  of  a  sequence  are  indexed  from  1  and.  unless  otherwise  noted,  sequences 
contain  at  least  one  element.  Note  that  in  the  abo\e  example.  n0  is  not  an  element  in  a 
sequence.  A  more  complicated  example  is  given  by  (proc  FIq  < n j  n ...  n^Q)  A]  A-. 
^m>0  A).  Here,  there  are  two  independent  sequences,  both  of  which  could  be  cmpt>. 

The  use  of  ellipses  in  denotational  semantics  is  not  limited  to  syntax  alone:  it  occurs  in  the 
semantic  equations  as  well.  As  pan  of  a  definitional  technique  whose  fone  is  its  mathematical 
precision,  these  ellipses  appear  at  first  to  be  somewhat  out  of  place.  Most  formal  definitions 
make  use  of  recursion  to  represent  such  iteration.  However,  it  is  not  the  notation  that  goes 
denotational  semantics  its  power,  but  the  mathematical  objects  (domains,  functions,  etc.)  being 
denoted.  The  use  of  ellipses  is  sufficient  as  a  notationa!  mechanism  in  that  it  is  unambigous. 
Indeed,  many  people  find  the  ellipses  to  be  a  much  more  natural  means  of  representation  than 
the  recursion  mechanisms  which  they  replace. 

3.2  Semantics 

The  denotational  semantics  of  a  programming  language  is  defined  by  means  of  functions  from  the 
set  of  programs  in  that  language  into  a  set  of  denotations.  In  the  case  of  AMDL.  we  will  be 
defining  a  function  P  which  maps  elements  from  Pro  (the  set  of  programs)  into  elements  from 
ANS  (the  set  of  answers),  otherwise  written  as  P:Pro-*ANS.  The  function  P  is  known  as  the 
semantic  function  for  the  syntactic  domain  Pro  and  is  specified  by  a  semantic  equation.  The  result 
obtained  from  applying  P  to  an  AMDL  program  is  known  as  the  denotation  of  that  program. 

Before  we  can  define  the  semantic  functions,  however,  we  must  introduce  some  semantic  domains. 
These  domains  define  the  types  of  objects  with  which  the  semantic  functions  will  be  dealing.  A 
simple  example  of  a  pair  of  semantic  domain  definitions  is: 

v:V  =  {0.1 }  Bits 

/?:B  =  V+  Bit  Strings 

fhis  says  first  that  V  is  ti  e  domain  of  "bits."  modeled  by  the  set  consisting  of  the  integers  0  and 
1.  Furthermore,  elements  from  V  will  be  represented  by  variables  of  the  form  v.  v.,.  v2  etc. 
Then  a  new  domain  B  is  defined  in  terms  of  V.  The  notation  V  +  is  used  to  represent  the  set  of 
all  finite,  nonempty  sequences  of  elements  from  V. 

We  also  will  need  to  introduce  some  operations  on  these  domains.  Since  this  report  is  concerned 
with  descriptive  semantics,  we  will  not  provide  rigorous  definitions  for  these  operations.  It  is 
assumed,  however,  that  the  domains  upon  which  these  function  operate  are  chain-complete, 
partially-ordered  sets,  or  CPO's.  and  that  furthermore,  these  functions  are  continous  over  CPO's. 

A  more  thorough  treatment  of  this  subject  can  be  found  in  [Milne  &.  Strachey.  1976],  which 
draws  the  initial  work  of  Scott  [Scott.  1976). 


19 


Sequences 


<d1.d2...  dn> 

\  list  containing  the  elements  d1  ,d2  .  dn 

tfd 

Number  of  elements  in  d  lex.  jS‘<d1.d2.  dn>  =  n) 

dii 

The  ith  element  of  d  (ex.  <d1  ,d2.  .dn>Ai  -d  ) 

df  i 

The  ith  tail  ofd 

lex.  <dvd2 . dp>ti  =  <dj  +  1  .d,  +  2 . dn>.  0<.<n) 

d§e 

The  concatenation  of  d  and  e 

(ex.  <dii>  §  dti  =  dt(i-  1),  1<K#d) 

Function  Spaces 

D-,  -»D2  =  {f  |  FD-,  -»D2  and  f  is  continuous} 

Products 

Di  XD2X  ...  XDn  =  {<d1.d2 . dn>  |  dj€Dj.  .=  1,2.3 . n) 

Sequences 

D+  ={<d1.d2 . dn>  | dj€D  i  =  1.2... } 


Sums 


D  ={<dv 

d2. 

...dn 

>  |  dj€D.  i  =  0.1,2. 

...} 

Di  +  D2 

..  -f 

Dn  = 

{<dj,i>  |  i  *  1,2 . 

n  and 

/ 

true 

if  d  =  <dj.i> 

d€Dj  = 

1 

false 

i  if d  =  <dj.j>  and 

j*i 

\ 

_L 

lfd  =  X 

d|Dj  = 

/ 

di 

ifd  =  <dj.i> 

\ 

± 

otherw  ise 

dj  in  D  = 

<d 

'ji> 

Notes: 

1.  IFie  symbol  €  introduced  above  is  identical  in  design  to  the  standard 
set  membership  €.  It  can  only  be  distinguished  by  its  size.  In  the 
semantic  equations.  6  is  used  almost  exclusively. 


2.  It  is  conventional  to  let  context  denote  whether  an  element  is  in  Dj 
or  in  D  =  D1  +  D2  +  ...  +  Dn.  Specifically: 

(a)  If  dj€D|  occurs  in  a  context  requiring  a  member  of 
D  =  D-|  +  D2  +  ...  +  Dn.  then  "dj"  should  be  interpreted  as 
"dj  in  D.” 

(b)  If  d€D1  +  D2+ ...  +  Dn  occurs  in  a  context  requiring  a 
member  of  Dj.  then  "d"  should  be  interpreted  as  "d|Dj." 

Phc  semantic  functions  will  be  defined  by  first  going  their  associated  function  space,  as  in  the 
following  example: 
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A.Act— U— G  — C  —  C 


which  says  that  the  semantic  function  A  is  a  member  of  the  function  space  Act-*U-»G-»C-»C. 
Semantic  functions  are  gi\cn  by  one  or  two  letters  in  the  italic  type  shown.  The  notation 
Act-»U-*G— »C— *C  is  short  for  Act— ►(U-»(G-»(C-*C))).  In  fact,  this  specific  domain  could 
have  been  defined  (though  not  identically)  as  A:(ActXUXGXC)-»C.  However,  the  practice  of 
utilizing  the  "cascading"  function  space  (known  as  currying)  has  advantages  in  terms  of  a 
shortened  notation. 

After  the  semantic  domains  have  been  given  for  the  functions,  a  set  of  equations  will  be  given. 
In  general,  one  equation  will  be  given  for  each  syntactic  case.  Conventions  used  within  these 
equations  are  as  follows: 

Xa/iy.E  is  equivalent  to  Xa.(X/3.(Xy.E)))  for  any  E 
F a/iy  is  equivalent  to  ((F(a))(j3))(y) 

Fa/S  =  E  is  equivalent  to  F  =  A a/S.E 
*  °j3°y  =  y(P(a))) 

a-»E1  ,/?-*E2.E3  means  "!f  a  then  E^  else  if  /?  then  E2:  else  E3" 

F[a/i]  =  An.(n  =  i)-*a.F(n) 

Bold  square  brackets  []  will  surround  any  syntactic  element  used  as  an  argument  to 
functions. 

During  the  definition  of  the  semantic  function,  it  will  become  necessary  to  introduce  some 
auxiliary  or  support  functions.  These  functions  will  always  be  represented  using  italicized, 
boldface  type  as  in  support.  These  functions  will  be  introduced  as  they  are  needed,  but  are 
listed  again  in  the  appendix  for  reference. 
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4.0  Formal  Definition  of  AMDL 

This  scciion  presents  a  complete  definition  of  AMDL  using  the  techniques  of  descriptive 
denotational  semantics.  First,  the  syntax  of  the  language  is  defined  through  a  set  of  BNF-like 
productions.  Second,  a  set  of  semantic  domains  arc  introduced  which  form  the  framework 
around  which  the  definuio"  “ill  be  built.  F'inally,  the  semantic  equations  associated  with  each 
syntactic  production  in  the  language  are  given.  Together  these  components  serve  to  totally  define 
the  meaning  of  any  AMDL  program. 

4. 1  Syntax 

In  Section  2.  we  informally  examined  AMDL  and  its  syntax.  We  used  metaexpressions  such  as 
(word  id  exp)  where  the  terms  id  and* exp  were  loosely  associated  with  the  domains  of 
identifiers  and  expressions,  respectively.  Then  in  Section  3.  we  introduced  a  slightly  more  formal 
notation,  fhis  second  notation  will  be  used  from  now  on  out.  Some  slight  differences  in 
organization  from  the  earlier  section  may  be  noted,  but  the  definitions  are  equivalent.  The 
complete  definition  follows  and  is  reproduced  in  the  appendix. 


4.1.1 

Syntactic 

Domains 

A:Act 

Actions 

B:Bin 

Binary  Operators 

X:Con 

Constants 

Z.Dcl 

Decode  Clauses 

A:  Dec 

Declarations 

E:Exp 

Expressions 

I:lde 

Identifiers 

N:Num 

Numerals 

P:Ref 

Variable  References 

K:SRf 

Structure  References 

Z:Str 

Structures 

T:Tra 

Transfer  Operators 

T:Una 

Unary  Operators 

ITVar 

Variables 

4.1.2 

Syntactic 

Equations 

A  ::=  (cond  (E  A))  |  (decode  E  Zj  Z2  ...  Zn)  |  (label  1  A)  |  (leave  I)  | 
(restart  I)  |  (resume  I)  |  (repeat  A)  |  (seq  Aj  A2  ...  An)  | 

(par  Aj  A2  ...  An)  |  (call  1  Ej  E2  ...  En>o)  I  E  I  (write  E) 

B  ::  =  usplus  |  usdifference  |  ustimes  |  usquotient  |  usremainder  | 
useql  |  usneq  |  uslss  |  usgtr  |  usleq  |  usgeq  |  ustst  | 
tcplus  |  tcdifference  |  tetimes  |  tequotient  |  tcremainder  | 
tceql  |  teneq  |  tclss  |  tegtr  |  tcleq  |  tegeq  |  tetst  | 
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ussrO  |  ussrl  |  ussrr  |  ussrd  |  usslO  |  ussll  |  usslr  |  ussld  | 

usor  |  usxor  |  usand  |  useqv  | 

usconc 

X::=  (bconst  N1  i\2)  |  (hconst  V,  \2)  |  (oconst  N-,  N2)  |  N 

Z::=  ((2^  22  ...  2n)  A)  |  (2  A)  |  A  |  (otherwise  A) 

A  ::=  (proc  fig  (FI j  IIt  ...  I~ln>g)  Aj  A2  ...  Am>g  A)  |  (over  rig  (Ilj  n2  ...  I~In))  | 

n 

E  ::  =  (ussub  E  K)  |  (B  Ej  E2)  |  (T  E)  |  (call  P  E]  E2  .  En>0)  | 

(T  (Pj  P2  ...  Pn)  E))  |  P 

1  ::  =  The  set  of  legal  identifiers 

N  ::  =  The  set  of  numerals  consisting  of  the  digits  0-9 

P  ::  =  (words  (bits  1  K)  E)  |  (words  1  E)  |  (bits  1  K)  |  I 

K  ::=  (pair  Xj  X2)  |  E 

2  ::=  (pair  Xj  X2)  |  X 

T::=  usset  |  tcset 

T::=  tcminus  |  usnot 

n  ::=  (words  (bits  1  2j)  22)  |  (words  I  2)  |  (bits  1  2)  |  I 
4.2  Semantic  Domains 


4.2.1  Datatypes 


The  only  datatype  in  AMDL  is  the  bitstring.  There  are  no  integers  or  booleans  as  they  occur  in 
other  programming  languages.  17ie  definitions  relating  to  bitstrings  are  as  follows: 

v:V  =  {0,1 }  Bits 

p:B  =  V+  Bit  Strings 

e:E  =  {<m,n>|m,n€N.  n>0,  0<m<2n-1}  Expression  Values 

The  first  two  domains  are  straightforward,  but  the  third  might  be  somewhat  puzzling.  The 
elements  of  E  are  simply  other  (equivalent)  representations  for  bitstrings.  This  representation 
turns  out  to  be  more  convenient  in  several  places  in  the  definition.  An  element  from  E  can  be 
thought  of  as  a  <value.length>  pair,  where  value  is  the  base-two  integer  value  of  the  bitstring  that 
is  being  represented  and  length  is  the  number  of  bits  in  the  bitstring. 


There  are  some  additional  datatypes  which  are  used  during  the  course  of  the  definition: 


t:T  =  {true, false} 
m,n:N  =  {0,1,2,...} 
z:Z  =  {...,-  2,  -  1,0, 1,2,...} 
p:P  =  NXN 
0  =  {©} 


Booleans 

Non-negative  Integers 

Integers 

Pairs  of  N 

Set  consisting  of  the  "undeclared" 
element 
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•  4  is.  y — 


ERR  =  N 
OUT  =  N 

ANS  =  (ERR  +  OUT) 


Error  codes 

Output  from  write  action 
Final  answers 


The  domain  0  is  used  primarily  in  constructing  the  target  domain  of  functions  which  need  to 
return  a  "undeclared"  or  "undefined"  value.  The  last  three  lines  describe  the  domain  ANS  which 
models  the  meaning  of  an  AMDL  program  as  a  sequence  of  output  and  error  codes.  It  will  be 
seen  later  that  if  an  error  code  appears  in  one  of  these  sequences,  it  will  be  the  last  element  in 
the  sequence  (corresponding  to  a  program  error  abort). 

4.2.2  Stores 

A  store  is  a  function  used  to  model  some  type  of  memory.  As  is  commonly  done,  we  will 
represent  our  store  as  a  mapping  from  a  set  of  locations  into  a  set  of  storable  values.  In  order  to 
not  commit  ourselves  to  any  particular  location  scheme,  we  w  ill  simply  define  the  set  of  locations 
L  as  "any  countably  infinite  set."  If  we  had  chosen  some  finite  set.  then  we  would  have  had  to 
address  the  problem  of  running  out  of  locations.  We  could  have  let  L  be  the  set  of  nonnegative 
integers,  but  there  was  no  reason  to  be  that  specific. 

Most  storable  values  in  present-day  computers  are  words  of  a  fixed  length.  For  reasons  which 
will  become  evident  as  we  proceed,  we  will  use  bits  rather  than  words  as  our  storable  values.  We 
w  ill  also  find  it  useful  to  include  the  set  F  of  function  abstractions  and  the  set  0  in  our  set  of 
storable  \alues.  F  will  be  described  later.  Our  domain  for  stores,  then,  looks  like: 

ct:S  =  L— »(V  +  F  +  0)  Stores 

4.2.3  Variable  Descriptors 

It  was  mentioned  earlier  that  the  primary  AMDL  datatype  is  the  bitstring.  But  notice  that  we 
have  not  included  bitstrings  in  our  set  of  storable  values.  In  order  that  we  may  w'ork  with  stored 
bitstrings.  we  introduce  the  following  two  domains: 

w:W  =  L  +  Word  Location  Strings 

a:A  =  W+  Array  Location  Strings 

Word  location  strings  are  simply  a  nonempty  sequence  of  locations,  and  array  location  strings  are 
simply  a  sequence  of  word  location  strings. 

AMDL  variables,  however,  come  in  varying  lengths  and  indexing  schemes  (e.g..  (bits  (words 
foo  (pair  0  15))  (pair  7  4))  or  foo[0:15]<4>).  Our  description  for  variables  must  include  this 
additional  information.  The  following  domains  are  introduced  for  this  purpose: 

w:WORD  =  WXP  Word  Variable  Descriptors 

a:ARRAY  =  AXPXP  Array  Variable  Descriptors 

The  P  component  of  a  WORD  is  a  pair  of  numbers  which  give  the  left  and  right  bitnames  of  the 
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word  variable  being  described.  The  ARRAY  domain  requires  two  P  components.  The  first 
describes  the  bitnames.  as  in  a  WORD,  but  the  second  is  needed  to  describe  the  wordnames  of  the 
array.  For  example,  if  "a"  is  an  array  variable  descriptor  being  used  to  describe  the  variable  foo 
declared  by 

(bits  (words  foo  (pair  0  15))  (pair  7  4)) 
then  a  of  the  form 

a=  <a.  <7,4>.  <0,15>> 

for  some  a.  For  example,  then,  the  expression  a±3A2  (  =  15)  can  be  used  to  access  the  index  of 
the  rightmost  word. 

4.2.4  Continuations 

'Hie  theory  of  continuations  is  fundamental  to  descriptive  denotational  semantics  and  to  this 
definition  in  particular.  Anyone  who  is  not  comfortable  with  the  idea  of  continuations  after 
reading  these  few  paragraphs  is  strongly  urged  to  consult  one  of  the  references.  The  AMDL 
definition  contains  several  types  of  continuations.  Basically,  a  continuation  is  employed  in  the 
semantic  definition  of  any  AMDL  construct  whose  evalutation  might  result  in  a  change  in  the 
sequential  flow'  of  control,  due  to  the  possibility  of  errors,  branches  or  similar  occurrences.  As  it 
turns  out.  most  of  the  AMDL.  constructs  fall  into  this  category,  including  the  three  major  ones: 
declarations,  actions  and  expressions. 

Continuations  are  functions  from  intermediate  results  to  final  answers.  Intermediate  results  can 
be  thought  of  as  the  results  produced  by  an  indiv  idual  construct.  For  instance,  the  intermediate 
result  of  a  constant  is  simply  the  value  of  that  constant.  The  intermediate  result  of  an  assignment 
action  is  a  new  store.  The  intermediate  result  of  an  assignment  expression  (an  assignment  used  as 
an  expression)  is  both  a  new  store  and  a  value.  The  continuations  for  the  various  types  of 
constructs,  therefore,  are  functions  whose  domains  are  the  various  types  of  intermediate  results. 

But  why  have  continuations  at  all?  Why  not  let  the  denotation  of  a  construct  simply  be  its 
intermediate  result?  To  see  the  answer  to  this,  consider  the  assignment  action.  As  mentioned 
earlier,  an  assignment  action  produces  a  new  store  from  an  old  store.  One  might  suggest,  then, 
that  the  domain  for  action  semantics  should  be  that  of  store-to-store  functions.  But  what  about 
the  branching  actions  (e.g.,  leave,  restart,  resume).  These  seem  to  leave  the  store  unchanged, 
but  their  denotation  would  certainly  not  be  the  identity  function  on  stores!  We  need  to  convey, 
somehow,  that  these  branching  actions  change  the  normal,  sequential  course  of  events.  This 
problem  is  solv  ed  by  letting  the  denotation  of  an  action  be  a  function  of  the  rest  of  the  program. 
where  rest  of  the  program  refers  to  all  of  the  remaining  computation.  More  precisely,  we  let  the 
denotation  of  an  action  be  a  function  of  an  action  continuation  whose  domain  is  given  by 


25 


O.C  =  S— >ANS 


Action  Continuations 


If  an  action  does  not  cause  a  branch,  it  simply  applies  its  continuation  argument  to  the  new  store 
that  it  produced.  If  a  branch  is  desired,  some  other  function  (say  a  jump  j)  is  applied  instead. 

Expressions.  as  mentioned  earlier,  produce  a  value  in  addition  to  a  new  store.  But  they.  too.  may 
alter  the  flow  of  control.  Division  by  zero  or  procedure  calls  which  take  abnormal  returns  are 
two  ways  in  which  this  may  happen.  The  domain  of  expression  continuations  is  defined  as 
follows: 


k:K  =  (EXS)— »ANS 

That  is,  expression  continuations  are  functions  of  expression  values  and  stores.  But  by  currying 
the  above  domain,  we  get 

k:K  =  E— »S— ►  AIMS 

which  further  reduces  to 

k:K  =  E-*C  Expression  Continuations 

This  type  of  simplification  will  be  performed  frequently  throughout  the  definition,  usually  without 
noting  the  intermediate  steps. 

The  next  ty  pe  of  continuation  is  for  structure  references.  A  structure  reference  is  that  component 
of  a  variable  reference  that  references  specific  bits.  A  continuation  is  needed  because  a  structure 
reference  may  be  an  expression,  and  an  expression  requires  a  continuation.  The  intermediate 
result  of  a  structure  reference,  though,  is  a  number  pair  p  and  (due  to  the  presence  of  an 
expression  within  the  structure  reference)  a  new  store.  This  leads  to 

=  P-*C  Structure  Reference  Continuations 

But  how  can  this  continuation  be  used  as  an  expression  continuation?  Quite  easily,  as  will  be 
shown  later. 

Variable  references  also  require  their  own  continuation.  The  intermediate  result  of  a  variable 
reference  is  a  word  location  string  and  a  new  store.  A  variable  reference  must  produce  a  word 
location  string,  rather  than  simply  a  bitstring,  because  variable  references  occur  in  the  destination 
component  of  assignment  statements  as  well  as  in  expressions.  This  gives  us: 

t):H  =  W— »C  Variable  Reference  Continuations 

The  rest  of  the  continuations  arc  somewhat  more  complicated,  involve  some  domains  which  have 
not  yet  been  defined,  and  will  be  covered  in  the  corresponding  section  on  the  semantic  equations. 
They  are  listed  here  for  completeness: 
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o:0  =  A— »ANS 
X:X  =  Q— >U-*C 

y:G  =  L-*((JX(J  +  0)X(J  +  0))  +  0) 


Overlav  Continuations 
Declaration  Continuations 
Procedure  Abstraction  Continuations 


4.2.5  Other  Domains 

Before  we  look  at  the  environment  domain,  there  are  few  other  domains  that  deserve  attention. 
One  of  the  interesting  results  of  the  theory  of  continuations  is  that  the  semantics  of  a  program 
"jump",  rather  than  providing  great  difficulties,  becomes  quite  simple.  In  this  case,  a  "jump"  is 
simply  an  action  continuation.  This  makes  sense,  in  that  a  jump  merely  directs  the  computation 
to  a  different  rest  of  the  program.  So.  we  have: 

j:J  =  C  Jumps 

We  have  not  said  anything  yet  about  how  we  are  intending  to  model  the  meaning  of  an  AMDL 
procedure.  We  introduce  the  notion  of  a  procedure  abstraction  as  follows: 

f:F  =  E  -*G-»C  Procedure  Abstractions 

This  models  a  procedure  as  a  function  of  a  sequence  of  expression  values  (corresponding  to  the 
arguments  of  the  procedure),  a  procedure  abstraction  continuation  G  (to  be  discussed  later)  and  a 
store  (embedded  in  C). 

In  order  that  we  may  have  a  way  of  determining  which  variables  have  been  bound  at  a  particular 
textual  point  in  an  AMDL  program,  we  introduce  the  domain 

q:Q  =  Ide — *■  ({true}  +  0)  Local  Binding  Functions 

which  we  will  use  for  this  purpose. 

We  also  introduce  the  domain  D  which  will  be  a  "universal”  domain  to  be  used  by  support 
functions  whose  arguments  are.  in  a  sense,  type  less. 

6:D  =  All  Finite  domains  which  can  be  constructed  from  given  primitive  domains  and  a 
finite  number  of  construction  operations. 

We  will  also  have  occasion  to  use  5  as  a  variable  in  places  where  it  is  necessary  to  represent 
elements  from  domains  not  explicitly  mentioned. 

4.2.6  Environment 

An  environment  is  used  to  associate  semantic  information  with  program  identifiers.  In  the  case  of 
AMDL.  this  information  deals  w  ith  variables,  procedures  and  labels.  If  an  identifier  can  be  used 
as  a  variable,  the  environment  associates  a  variable  descriptor  (either  word  or  array)  with  that 
identifier.  Different  environments  ma>  be  in  force  at  different  times  in  the  program.  Therefore, 
the  semantic  information  associated  with  a  given  identifier  depends  upon  the  environment  in 
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whose  range  it  lies.  If  an  identifier  can  be  used  as  a  procedure,  then  the  environment  tells  how 
mans  parameters  that  procedure  must  have  and  provides  a  pointer  to  a  procedure  abstraction. 
(The  reason  for  using  a  pointer  will  be  seen  later.)  Finally,  if  an  identifier  is  used  as  a  label,  then 
the  environment  contains  jumps  (members  of  J)  which  are  to  be  used  during  branches  to  that 
label.  There  is  a  fourth  component  to  the  environment,  which  is  used  to  contain  the  unique 
location  associated  with  the  procedure  in  which  the  environment  is  being  used.  This  fourth 
component  can  be  ignored  for  the  time  being.  Our  domain,  then  looks  like 

p:U  =  UVARXUPROCXULABXL 
UVAR  =  (Ide— ‘(ARRAY  +  WORD  +  0)) 

UPROC  =  (lde—((LXN)  +  0)) 

ULAB  =  (Ide — ►  ((JX  J)  +  0)) 

The  reader  should  try  to  familiarize  himself  with  the  above  environment  domain,  as  it  will  be 
used  frequently  throughout  the  definition.  If  this  is  too  difficult,  simply  remember  that  the  first 
component  deals  w  ith  variable  definition,  the  second  with  procedure  definition,  and  the  third  with 
labels.  The  context  in  which  the  components  are  used  should  provide  some  additional  help. 
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4.3  Semantic  Functions 


We  are  now  ready  to  look  at  the  heart  of  the  definition,  the  semantic  functions.  For  each 
construct,  we  will  provide  a  semantic  domain  and  a  set  of  semantic  equations  which  will 
collectively  define  the  construct's  semantics.  The  domains  and  equations  will  be  discussed  in 
detail  and  related  to  actual  programming  situations.  In  some  cases,  a  number  of  alternative 
semantic  interpretations  and  their  denotations  will  be  discussed. 

The  constructs  will  be  presented  in  an  order  that  will  facilitate  a  bottom-up  assimilation  of  the 
definition.  There  will  be  some  forward  references,  but  these  will  be  clearly  noted  when  present. 
The  unary  and  binary  operators,  due  to  their  number,  will  be  presented  last.  Several  "support" 
functions  will  appear  throughout  the  semantic  equations  as  they  art  required. 

4.3.1  Idea  lifters 

There  is  no  semantic  (unction  for  identifiers.  Elements  from  Ide  are  used  directly  in  the  semantic 
equations. 

4.3.2  Numbers  (A/:Num-»N) 

The  semantic  function  N  maps  elements  from  Num  into  their  decimal  interpretation.  This 
function  is  not  defined  by  any  equation. 

4.3.3  Constants  (C:Con-»E) 

The  semantic  function  C  maps  constants  into  expression  values.  The  first  three  types  of  constants 
explicitly  specify  their  value  and  length,  so  C  is  just  given  by 

C[(bconst  N1  N2)]  =  <W[Ni],A/[N2]> 

C[(hconst  N-,  N2)]  =  <N[N-|],A/[N'2]> 

C[(oconst  N’i  N2)]  =  <N[N1],N[N2]> 

The  other  type  of  constant  is  simply  a  numeral  N.  whose  meaning  is  an  expression  consisting  of  a 
value  N[N]  and  a  length  equal  to  one  greater  than  the  number  of  bits  required  to  represent  N. 
Some  question  arises  as  to  the  length  when  N[N]  =  0.  In  some  sense,  it  takes  one  bit  to  represent 
"0".  because  no  bits  have  no  meaning.  On  the  other  hand,  it  could  be  argued  that  it  should  take 
one  more  bit  to  represent  a  "1"  than  a  "0".  for  the  same  reason  that  it  takes  one  more  bit  to 
represent  (say)  a  "4”  than  a  "2".  We  have  chosen  the  latter  alternative  and  defined  the  length  of 
"0"  to  be  one  (that  is.  one  more  than  zero).  So.  the  definition  of  C  is  completed  by 

C[N]  =  <N[S],int/og(N[N])  +  2> 

for  N[S]>1 

C[N]  =  <0,1  > 
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for  A/[N]  =  0 

where  ir>tlog( n)  gi\es  the  integer  part  of  log2  n. 

4.3.4  Structure  References  (K:SRf-»U— ►G->M— 1 >C) 

A  structure  reference  is  either  a  pair  of  constants,  as  in  (pair  X2)  or  an  expression  E.  This  is 
the  mechanism  used  to  refer  to  a  particular  bit  field  in  a  variable  reference.  Because  of  the 
possible  occurrence  of  an  arbitrary  expression  inside  of  a  structure  reference,  the  semantic 
function  K  must  be  a  function  of  the  environment  p.  a  procedure  continuation  y.  a  structure 
reference  continuation  p.  and  a  store  a.  (Again,  note  that  K  could  also  be  viewed  as  a  member 
of  [(SRfXUXGXMXS)-»ANS],  but  that  the  above  notation  lends  itself  to  shorter  definitions.) 
Not  all  of  these  arguments  are  used  in  the  case  of  the  pair  of  constants,  whose  semantic  equation 
is 

(Kl)  K[(pair  Xj  X2)]pyp  =  p(C[X1]41.C[X2]41) 

That  is.  the  structure  reference  continuation  is  applied  to  the  value  portions  of  the  two  constants, 
and  the  other  arguments  are  ignored.  The  equation  for  the  case  of  the  expression  shows  how  one 
type  of  continuation  is  utilized  in  creating  another  type  of  continuation.  Here,  we  have 

(K2)  K[E]pyp  =  E[E]py{\e.p(el1.e'l'1)} 

This  says  that  the  meaning  of  a  structure  reference  E  is  the  meaning  of  £[E]  with  the  same 
environment  and  procedure  continuation,  but  with  a  new  expression  continuation.  This 
expression  continuation.  {Ae.p(ei l.eil)}.  takes  the  expression  value  and  uses  its  value 
component  as  both  arguments  to  the  structure  reference  continuation.  In  other  words,  when  a 
single  expression  is  used  as  a  structure  reference  it  is  referring  to  a  single  bit. 

4.3.5  Variable  References  (ft:Ref-»U— »G-*H-*C,  R/:Ref— »lde) 

There  are  two  semantic  functions  listed  abo\e.  The  second  function  Rl  w  ill  be  necessary  later  on. 
It  simply  returns  the  identifier  contained  within  the  construct. 

(RI1)  R/[(words  (bits  I  K)  E)]  =  I 
(RI2)  R/[(words  I  E)]  =  l 
(RI3)  R/[( bits  I  K)]  =  I 
(RI4)  R/[I]  =  I 

The  other  function.  R.  is  the  function  which  allows  access  to  variables.  As  discussed  earlier,  its 
intennediate  result  is  a  location  string.  There  are  several  things,  though,  which  must  be  true  for  a 
reference  to  be  valid: 

0  The  variable  must  be  defined  (i.e..  in  the  environment). 

°  The  variable  must  be  accessed  in  the  right  mode  (words  as  words,  arrays 
as  arrays). 
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0  The  bit  or  word  references  must  be  within  bounds. 

If  any  of  these  conditions  is  not  satisfied,  then  the  program  is  considered  to  be  in  error.  How. 
though,  is  an  error  condition  represented  in  the  conditions?  First,  recall  that  the  semantic 
function  PROG  is  a  function  from  programs  into  answers,  where  answers  are  modeled  bv  the 
domain  ANS  =  (OUT  +  ERR)*,  with  the  domains  OUT  and  ERR  being  equivalent  to  the  domain 
of  nonnegative  integers.  N.  That  is  to  say.  an  answer  is  essentially  a  sequence  of  zero  or  more 
nonnegative  integers,  lagged  as  to  whether  they  are  from  the  domain  OUT  or  from  the  domain 
ERR.  The  elements  from  OUT  are  generated  by  evaluation  of  write  statements.  The  elements 
from  ERR.  however,  are  generated  when  a  run-time  error  occurs  via  functions  such  as  err.  whose 
definition  follows: 

(SF7)  errN->S— »ANS  Program  Error 

err(n)<T  =  <n  in  ERR> 

Given  an  argument  N  (used  to  denote  an  error  number)  and  a  store  a.  it  produces  a  sequence 
consisting  of  the  single  element  "n  in  ERR".  A  list  of  error  codes  and  their  meanings  can  be 
found  in  the  appendix.  Although  the  store  is  not  used  in  the  definition,  it  is  present  because  the 
err  function  is  frequently  used  in  places  where  it  is  desirable  to  return  a  function  of  type 
S-*ANS  or  C.  It  might  be  more  appropriate  to  think  of  the  definition  of  err  as 

err:  N-»C 

err(n)  =  (Aa.<n  in  ERR>) 

We  return  now  to  our  discussion  of  the  semantics  of  variable  references.  Taking  the  simplest  case 
first,  we  have 

(R4)  F?[I]pyT7  = 

5$WORD—  err(11). 

»/(541) 

where  5  =  P41[I] 

which  looks  at  the  variable  portion  of  the  environment  applied  to  the  identifier  I  and  calls  it  5. 
If  5  is  undefined  or  is  an  ARRAY,  then  an  error  has  occurred.  Otherwise,  the  variable  reference 
continuation  t)  is  applied  to  the  entire  location  string  541. 

The  second  case  we  will  look  at  involves  specific  bit  references.  Here,  we  must  first  determine 
that  the  bit  reference  is  valid  and  then  reference  the  appropriate  bits.  Determining  the  validity  of 
the  bit  reference  is  done  via  the  support  function  legal 

(SF10)  lega!:( PXP)-*T  Determines  if  access  is  legal 

/ega/(p1,p2)  = 

p24 1  <p242-(p24 1  <p,  41  <Pl  42<p242). 

(p241>p141>pi42>p242) 

legal  is  a  function  of  two  nonnegative  integer  pairs  p1  and  p2.  The  pair  p2  is  interpreted  as  a 
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declared  indexing  scheme.  That  is.  p2l1  goes  the  leftmost  index  and  p2i2  gixes  the  rightmost 
index.  The  pair  p1  is  interpreted  as  the  reference.  What  the  function  does  is  to  first  determine 
whether  the  indexing  scheme  described  b>  p2  is  ascending  or  descending  and  then  to  determine 
whether  the  pair  p1  is  an  appropriate  reference  gi\en  that  scheme. 

After  determining  that  a  reference  is  legal,  the  reference  must  be  made.  Because  AMDL  supports 
such  a  wide  range  of  indexing  schemes,  references  are  first  converted  to  normalized  form. 
Normalized  form  is  that  w  hich  allow  s  us  to  extract  elements  from  a  sequence  using  the  standard 
operation  "A".  That  is.  we  will  assume  sequences  are  indexed  from  left  to  right,  beginning  with 
1.  and  that  normalized  references  assume  this  indexing  method.  We  introduce  a  normalization 
function  norm  which  performs  this  normalization  process. 

(SF13)  norm:(PXP)-»P  Normalizes  access 

norm(pvp2)  = 

p2^1  <p2^2-*<Pi  -H  -  P2i1  +  1,p1 12-  p2i1  +  1  >. 

<p241  -  p1  il  +  1  ,p2T  1  -  Pi  12  +  1  > 

for  /ega/(p1.p2). 

Giw.i  a  reference  p1  and  a  defining  pair  p2.  norm  returns  a  normalized  reference.  Rather  than 
stepping  through  the  definition,  we  will  give  a  few  examples 

norm(<  7,0>.<7,0>)  =  <1.8> 
r»orm(<2,3>.<0.15>)  =  <3.4> 
norm(<2,3>.<1,4>)=<2.3> 
norm(<  5.5>.<7.5>)  =  <3,3> 

The  actual  extraction  of  elements  from  a  sequence  is  done  via  the  function  extract,  defined  as 
follows: 

(SF8)  extract! PXD  +  )-»D+  Returns  sub-sequence  of  D  + 

ex/rac/(p,S)  = 

<6T(pT  1  ).6T((pT  1 )  +  1) . 5T(pT2)> 

for  1  < pT  1  <p!2<  it  8 

Let  us  now  examine  the  second  type  of  \ariable  reference. 

(R3)  P[(bits  1  K)]pyr)  = 

6$WORD— *err(11). 

K[K]py{Xp  “ '/ega/(p.6i2)-*err(40). 

ri(extract(norm(p,8l2).8i1))} 

where  6  =  p±1[I] 

First.  8  is  checked  to  see  that  is  has  a  WORD  definition,  as  before.  If  this  is  the  case,  then  K[K] 
is  evaluated  with  a  structure  reference  continuation  that  contains  the  appropriate  bounds 
checking.  In  this  continuation,  first  the  argument  p  is  checked  to  see  that  it  is  a  legal  access. 
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Ihis  is  done  in  /ega/(p,642).  which  compares  the  pair  p  with  the  hounds  from  the  environment 
64-2.  If  the  reference  is  legal,  then  no  more  errors  arc  possible  and  the  original  variable  reference 
continuation  may  be  applied  to  the  appropriate  subset  of  the  location  string  for  that  variable. 
ITiis  subset  is  found  by  first  normalizing  the  reference  p  (norm(p,8i2))  and  then  extracting  the 
appropriate  locations  (exfracf(norm(p.642).54l)). 

Io  determine  whether  bit  references  outside  of  the  defined  boundaries  arc  valid  in  this  case,  the 
function  legal  can  be  consulted.  It  will  show  that  this  is  not  allowed. 

Hie  next  type  of  variable  reference  involves  array  accesses.  Here,  we  must  perform  bounds 
checking  as  well,  but  rather  than  having  a  structure  reference  K  involved,  we  have  an  expression 

E. 

(R2)  fl[(words  I  EJJpyi?  = 

6£  ARRAY-»err(1 1,'. 

t  [E]py{Ae.  -i  legal!  <e4 1.  e41>.  6  43)  —  err(1 2), 

ij  ( exf  racf(  r7o/7T»(  <  e  4- 1  ,e  i  1  > ,  6  4- 3) .  6  4- 1 )  4- 1 ) } 

where  6  =  pi1[I] 

First.  6  is  checked,  as  it  must  be  an  ARRAY.  I  hen.  the  expression  E  is  evaluated  with  a 
continuation  similar  to  the  one  for  bit  reference.  Because  legal  expects  number  pairs,  we  form  a 
pair  <e41.e41>  where  eil  is  the  value  component  of  the  evaluated  expression.  We  then  call 
legal  with  this  pair  as  one  argument  and  the  array  bounds  (643)  as  the  other  argument.  If  the 
access  is  legal,  then  we  use  extract  and  norm  as  we  did  with  the  bit  reference,  except  in  this 
case  we  are  passing  an  array  location  string  to  extract  rather  than  a  word  location  string.  The 
result  is  that  we  get  back  a  list  of  one  element,  which  is  the  word  location  string  we  want.  This 
one  element  is  then  selected. 

Die  final  type  of  variable  reference  combines  both  a  bit  reference  and  a  word  reference.  The 
equation  for  this  type  simply  combines  the  operations  of  the  previous  equations. 

(Rl)  R[(words  (bits  I  K)  E)]pyT/  = 

6#ARRAY-»errf1 1). 

F[E]py{Xe.-i/egaf(<e41.e41>,643)— »err(12). 

K[K]pYp} 

where  6  =  pi1[l] 

p  =  (\p.-i/ega/(p.642)-»err(13), 

ri(extract(norm(p,8l2).u))} 
where  <a  =  exf/-acf(norm(<e41.e4l  >,643)  641)41 

Here  we  see  how  the  order  of  evaluation  of  the  components  of  the  construct,  in  this  case  the  K 
and  the  E.  is  specified.  By  giving  E[E]  a  continuation  with  includes  K[K]  we  are  specifying  that 
E  is  to  be  evaluated  first. 


Hie  question  of  speeding  the  order  of  evaluation  of  the  components  of  a  construct  is  a 
significant  one.  One  clearly.  then,  has  to  make  some  statement  concerning  this  evaluation.  One 
possible  statement  would  be  to  say  that  such  order  is  undefined.  This  would  heavily  discourage 
the  use  of  side-effect-producing  constructs  in  certain  situations,  although  it  would  admit  the 
possibility  of  programs  which  give  nonreproducible  results.  In  addition,  it  would  relieve  the 
programmer  from  having  to  memorize  possibly  complex  evaluation  rules.  On  the  other  hand,  we 
could  explicitly  state  the  order  in  which  constructs  are  evaluated.  This  would  permit  "side-effect 
programming",  provided  one  was  willing  to  memorize  the  evaluation  rules.  It  would  also  ensure 
programs  which  give  the  same  result  each  time  they  are  run.  There  are  arguments  for  both 
approaches.  Some  language  designers  have  avoided  the  problem  by  eliminating  side-effects  from 
important  constructs,  such  as  expressions.  In  this  definition,  we  have  chosen  to  specify  the  order 
of  evaluation  explicitly  ,  partly  due  to  the  simplicity  of  this  approach  from  a  notational  standpoint. 
However,  there  are  techniques  in  denotational  semantics  which  allow  one  to  specify  that  the  order 
of  evaluation  is  random.  These  techniques  are  discussed  in  [Milne  and  StracheyJ. 

4.3.6  Expressions  (f :Exp-»U->G-»K-*C) 

By  now.  we  have  come  to  expect  a  certain  kind  of  semantic  domain.  There  is  usually  an 
environment,  a  procedure  continuation,  a  continuation  for  the  particular  construct  and  a  store. 
The  semantic  function  E  follows  this  convention,  in  this  case  using  the  expression  continuation  K. 
K.  again,  is  the  set  of  functions  from  expression  values  and  stores  into  answers  (E — *-C). 

Before  we  can  examine  the  equations  however,  we  need  to  introduce  some  additional  support 
functions  which  will  allow  us  to  move  easily  between  expression  values  and  bitstrings. 

(SF5)  ecomz:B-*E  Converts  a  B  to  an  E 

econv(p)  =  <n  .#  (3> 
where  n  =  ( 44(3  -  , 

pi(#p)  +  2'(el  1)) 
e  =  eco.*"(exfracf(<1. 44  (3  -  1  >,/})) 

(SF4)  bconv:E-»B  Converts  an  E  to  a  B 

toconvfe)  =  [3 
such  that  econv(P)  =  e 

(SF14)  pwr(NXV)— »B  Generates  tuples  of  an  element  from  V 

pwr(  n.v)  =  <v-|.V2 . vn> 

where  vj  =  v.  i  =  1 .2 . n 

for  n>1 

(SF3)  adjust  { BXNXV)->B  Shortens  a  bitstring,  or  extends  it  on  the  left 

with  copies  of  a  given  element  from  V 

adjust(p.ny)  = 

n<  # p->extract(<  4f  p- n  +  1  .#/?>,/?), 
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pwr(n-  # p.v)§(3 


'Die  first  two  functions  econv  and  bconv  convert  between  expression  values  and  bitstrings.  The 
definition  of  bconv  can  simplv  be  the  inverse  of  econv  because  the  functions  are  one-to-one. 
The  function  pwr  generates  all-zero  or  all-one  bitstrings  and  is  used  by  adjust,  which  either 
extends  or  truncates  a  bitstring  on  the  left. 

The  first  type  of  expression  is  used  to  extract  a  bitfield  from  or  to  extend  another  expression. 
The  equation  is 

(El)  f [(ussub  E  K)]py»c  = 

£[E]pY{Xe.K[K]pyp} 

where  p  =  { \p.pi1>pi2-*K(econv(extract(norm(p,<n  -  1,0>), /?))), 
err(14)}, 

n  =  max(  pil  +  1  ,e!2) 
fj  =  adjust(bconv(e),n.O) 

E  is  evaluated  with  a  continuation  which  includes  the  evaluation  of  K.  K[K]  is  evaluated  with  a 
continuation  that  first  checks  that  the  resulting  structure  reference  is  legal.  In  this  situation, 
"legal"  means  that  the  first  number  is  greater  than  or  equal  to  the  second  number,  since  there  is 
an  implicit  indexing  of  the  bits  of  the  binarv  representation  of  expression  values  in  this  situation. 
'  which  is  ascending  right-to-left  beginning  with  zero.  If  the  pair  is  legal,  then  the  original 

expression  continuation  k  is  applied  to  the  appropriate  value.  This  value  is  formed  by  first  letting 
n  be  the  maximum  of  the  length  of  the  expression  and  the  leftmost  number  in  p  plus  1.  We 
then  create  a  bitstring  of  length  n,  with  the  assurance  that  we  can  then  legally  extract  a  subfield 
with  the  pair  p.  This  is  done  by  converting  the  expression  to  a  bitstring  with  bconv(e).  then 
passing  this  and  the  number  n  to  the  function  adjust  which  creates  a  new  bitstring  fj  of  length 
n,  padded,  if  necessary,  with  the  third  argument  0.  Bits  are  then  extracted  from  /?  using  the  pair 
p  normalized  to  the  aformentioned  indexing  scheme  (exfracf(norm(p,<n-1 ,0>),/})).  This 
resulting  bitstring  is  then  converted  to  an  expression  value  with  econv  and  the  result  passed  to 
the  expression  continuation  k. 

The  second  type  of  expression  involves  the  binarv  operators. 

(E2)  £[(B  Ej  E2)]P7k  = 

£[El]pY{^e-|  £[E2]PY{^e.|cr.B[B]tei.e2){;\e.K(e)a}}} 

Ej  is  evaluated,  followed  by  E2  and  both  results  passed  to  &[B],  Note  that  B  does  not  require 
an  environment  or  a  procedure  continuation.  This  is  because  it  operates  only  on  expression 
values.  It  does  require  a  continuation,  however,  because  it  may  result  in  an  error  (e.g..  div  ision 
by  zero).  The  continuation  for  binary  operators  is  a  function  from  expressions  into  answers.  This 
is  different  from  an  expression  continuation  which  is  a  function  from  an  expression  ami  a  store 
into  an  answer.  Consequently,  we  must  construct  the  continuation  {Ae.tc(e)a}  for  use  with  Bf B], 
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The  equation  for  expressions  involving  unary  operators  looks  similar,  except  that  the  unary 
operator  function  U  does  not  require  a  continuation.  Rather  it  returns  an  expression  value  which 
is  then  used  as  an  argument  to  the  expression  continuation.  The  equation  is  then 

(E3)  £[(T  E)]PYk  = 

E[E]py{\e.K(U[T](e)))} 

Before  we  look  at  the  fourth  type  of  expression,  it  is  time  that  we  examined  the  procedure 
continuation  domain  G  a  little  more  closely.  Elements  from  G  are  used  to  represent  something 
similar  to  a  run-time  stack  of  procedure  invocations.  It  is  actually  a  function  from  procedure 
pointers  (locations)  to  a  triple  of  "jumps".  These  jumps  correspond  to  the  rest  of  the  program  for 
a  leave,  restart,  and  resume  of  that  procedure.  This  definition  always  uses  the  variable  y  to 
represent  that  function.  At  any  point  in  the  computation,  y(l)  (where  I  is  a  location  associated 
with  a  procedure)  will  be  defined  for  exactly  those  procedures  which  are  currently  invoked.  This 
latter  fact  is  used  in  the  following  equation. 

The  fourth  type  of  expression  is  a  procedure  call.  Its  definition  requires  the  introduction  of  two 
more  support  functions. 

(SF22)  updafe:(D  +  XNXD)— >D  +  Sequence  update  function 

updates,  n,d)  = 

<641,642 . 64(n-  1),d,64(n  +  1).  ...  64(#6)> 

for  1  <n<  #  6 

(SF4.1)  de/-ef:(WXS)-*E  Dereference  function 

deref(u.o)  = 

econv(<<r(<a41).CT(ta42) .  o(u4(#<u))>) 

for  #w>1.  <r(w4i)€V.  i  =  1 .2 . w 

The  update  function  is  used  to  update  a  seq  icnce.  The  first  argument  6  is  the  sequence  to  be 
updated.  The  second  argument  n  gives  the  index  of  the  element  in  the  sequence  to  be  replaced, 
and  the  final  argument  d  is  the  new  element  to  be  inserted  The  function  returns  tire  updated 
sequence.  For  example.  updafe(<a.b.c>.2  d)  =  <ad.c>  Hie  dereference  function  simply 
interprets  a  word  location  string  with  respect  to  a  given  store 

With  these  support  functions  defined,  we  can  now  introduce  the  semantics  of  the  procedure  call. 

(E4)  f  [(call  P  Ej  E2  ...  En>o)Jpr*ff !  * 

6£0— »err2(9), 

642*n  —  err2(10), 
y(64l)C0  — err2(17), 

£[E]]pY{\ei  .F[E2]pY{Xe2  F[Enlpy 

{\en.a1(641)(e1.e2 . en)y,}  ...  jjcj 

where  6  =  p42(fl/[P]) 
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yj  =  Y[updafe(y(pf4).3,j)/pi4][<j,©,ffi>/541] 
j  =  fl[P]py{Xw(T2-K(c,e/'e^(w.ai))ai} 
n  is  the  subscript  of  En 

if  n  =  0.  then  the  last  clause  in  the  equation  reduces  to 
«t(64,1)(0)Yi 

rhe  first  thing  that  should  be  pointed  out  is  that  the  above  definition  uses  a  new  error  function. 
The  function  err2  is  identical  to  err  except  that  it  has  no  store  argument.  As  you  may  recall, 
we  introduced  the  store  argument  into  err  simply  as  a  convenience  and  that  it  was  irrelevant  to 
the  definition  of  err.  We  do  not  want  a  store  argument  in  this  case  because,  unlike  previous 
•'-ituations,  we  are  specifying  a  a  on  the  left-hand  side  of  the  equation.  The  a  appears  on  the  left- 
hand  side  of  the  equation  because  it  was  necessary  to  reference  it  on  the  right-hand  side. 

Let's  examine  the  above  equation  a  line  at  a  time.  8  is  defined  to  be  p42(fi/[P]).  the  procedure 
portion  of  the  environment  applied  to  the  identifier  contained  in  the  \ariable  reference.  The  first 
two  lines  of  the  equation  check  that  the  procedure  is  defined  and  that  the  number  of  formal  and 
actual  parameters  match.  The  third  line.  y(S41)$ 0-*err2(17).  checks  to  see  if  the  location 
associated  with  the  procedure  is  defined  in  y.  If  it  were,  then  that  would  mean  that  a  recursive 
procedure  call  is  being  attempted,  which  is  not  allowed. 

If  the  function  is  defined  and  the  call  is  not  recursive,  then  each  of  the  expressions  is  evaluated. 

beginning  with  the  first.  Then,  the  results  (e-|,e2 . en)  of  the  evaluation  are  passed  to  the 

procedure  abstraction  trj(64-1).  (The  location  (64-1)  provides  an  index  into  aj  which  produces  a 
procedure  absraction  of  type  F.)  This  result  is  then  further  applied  to  an  updated  procedure 
continuation,  yj.  upda/e(y(p44),3,j)  yields  an  updated  procedure  continuation  entry  for  the 
current  procedure,  whose  location  is  given  by  pi  A.  The  change  made  is  to  replace  the  third 
(resume)  component  with  the  new  jump  j.  This  jump  j  represents  what  the  rest  of  the  program 
is  to  be  for  the  case  of  a  resume  of  this  procedure.  The  procedure  continuation  is  further 
updated  by  setting  the  called  procedure's  entry  to  the  triple  <j,®,®>  which  serves  to  define  the 
leave  component,  leaving  the  other  two  entries  undefined.  (The  restart  component  will  get  set 
when  the  procedure  is  actually  entered.) 

Finally,  we  need  to  look  at  the  jump  j.  This  jump  will  evaluate  the  variable  reference  with  the 
current  environment  p.  the  current  procedure  abstraction  y.  and  a  new  store.  (The  use  of  the  new- 
store  is  implied  due  to  the  fact  that  the  right  hand  side  is  a  .function  of  an  unspecified  store.  If 
the  old  store  were  desired  for  the  variable  reference,  then  j  would  have  had  to  be  defined  by 
j  =  {Aaj.flfPlpyfAt^.Kfdere/fw.t^Jcrs}0]}  But  this  doesn't  make  much  sense,  because  the 
new  store  is  now  lost!)  The  continuation  passed  to  the  variable  reference  takes  a  location  string 
«  and  a  store  a  j  and  dereferences  the  location  string  in  that  store  {deref(u.02)),  resulting  in  an 
expression  value.  'ITiis  expression  value  is  then  passed  to  the  original  expression  continuation  k 
and  that  result  applied  to  the  store  ct->. 
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The  fifth  type  of  expression  is  the  assignment  or  transfer  expression.  Its  semantic  definition  is 
(E5)  £[(( P\  Pj  ...  Pn)  T  E))]pyK  = 

EtE]py{Xe.R[P1]py{Xw1.f?tP2lPf{^W2-  -  -  }}} 

where  17  =  {Xwna.«e(T[T]((ta1  §w2§  ...  §wn),e)<r)} 

lTie  variable  references  Pj  Pj  ...  Pn  constitute  the  left-hand  side  of  the  transfer  and  the 
expression  E  constitutes  the  right.  As  there  is  more  than  one  type  of  transfer  in  AMDL  the 
transfer  operator  has  its  own  syntactic  domain  T.  AMDL  transfers  allow  multiple  variable 
references  in  the  destination,  and  there  is  no  restriction  that  these  variable  references  be  disjoint. 
There  are  several  ways  in  which  this  transfer  could  be  defined,  but  let  us  first  look  at  the  above 
definition. 

First,  the  right-hand  side  expression  is  evaluated  with  a  continuation  that  includes  the  evaluation 
of  Pj.  The  continuation  of  fl[Pj]  includes  the  evaluation  of  P2  and  so  on.  The  continuation  77 
of  the  last  variable  reference  applies  the  original  expression  continuation  k  to  the  result  of 
evaluating  the  right-hand  expression.  This  result  is  further  applied  to  the  new  store  produced  by 
7Tn((«i§«2§  §wn),e)a-  The  arguments  to  7"[T]  are  the  concatenation  w1§w2§  ...  §can  of 

the  location  strings  produced  by  the  variable  references,  the  result  e  of  evaluating  the  right-hand 
side  expression,  and  the  current  store  a. 

While  w’e  would  need  to  examine  the  definition  of  T  in  order  to  determine  how  the  bits  of  the 
expression  are  assigned  to  the  left-hand  side,  there  are  many  observ  ations  that  can  be  made  from 
the  above  equation.  First  of  all.  the  order  of  ev  aluation  of  tine  components  of  the  construct  is  E. 

Pj.  P2 . Pn-  Secondly,  it  can  be  seen  that  no  assignment  takes  place  until  all  of  the  left-hand 

side  has  been  evaluated.  This  is  important  because  an  individual  assignment  could  affect  the 
evaluation  of  the  remaining  variable  references.  Finally,  we  see  that  the  original  expression 
continuation  is  applied  to  the  expression  value  returned  by  the  right-hand  side.  Another  possible 
interpretation  would  be  to  dereference  the  left-hand  side  after  making  the  assignment  and  to  use 
that  dereferenced  value  as  the  argument  to  the  expression  continuation.  This  dereferenced  value 
could,  of  course,  be  different  from  the  value  of  the  right-hand  side. 

The  next  expression  type  we  look  at  is  the  variable  reference.  The  meaning  of  a  variable 
reference  as  an  expression  is  simply  the  dereferenced  value  of  the  variable.  The  equation  is 

(E6)  £[P]pyK  =  R[P]pY{Xwa.K(deref(w,a))a} 

Note  that  dereferencing  must  be  done  with  respect  to  a  particular  store. 

Finally,  an  expression  can  be  a  constant.  The  semantics  are  defined  by 

(E7)  E[X]py k  =  ic(C[X]) 

The  term  C[X]  yields  an  expression  value  which  is  used  as  an  argument  to  the  expression 
continuation  k. 


38 


4.3.7  Transfer  Operators  (T:Tra— *(WXE)— >S— >-S) 


We  just  examined  the  role  of  the  transfer  operator  in  a  transfer  expression.  Its  semantics  is  to 
produce  a  new  store  from  an  old  one  by  updating  a  string  of  locations  with  a  particular 
expression  value.  Before  we  examine  the  equations  for  transfer  operators,  though,  we  need  two 
new  support  functions  which  will  allow  us  to  express  the  updating  of  stores  more  concisely. 

(SF17)  ieft>:(WXB)-»S-*S  Updates  an  S  with  a  B 

sefb(w,jS)a  =  a[j84.1/wl1][j812/w4-2]  ...  [fiH# 0)/ul(#  u)] 
for  #u=#/3  and  #  u>  1 

(SF18)  sefba:(WXB)-»S-*S  Updates  an  S  with  an  adjusted  B 

setba(u,/3)  =  setb(u,adjust((3,  tt  u.O)) 

The  function  setb  is  used  to  update  a  store,  given  a  location  string  and  a  bitstring.  Both  strings 
must  be  of  equal  length.  Note  the  semantics  of  the  "[]"  operator  tells  us  that  the  locations  are 
updated  from  left  to  right.  This  is  important  because  the  locations  within  a  location  string  need 
not  be  unique.  The  function  setba  is  identical  to  setb  except  that  its  bitstring  argument  need 
not  be  the  same  length  as  the  location  string  argument.  If  the  two  lengths  differ,  the  bitstring 
argument  is  adjusted  before  the  update  takes  place. 

There  are  two  transfer  operators,  corresponding  to  the  two  arithmetic  modes  of  AMDL,  unsigned 
and  two's-complement.  The  first  operator  is  usset  and  is  defined  by 

(Tl)  T[usset](w.e)  =  setba(u.bconv(e)) 

The  semantics  of  this  operator  is  just  the  semantics  of  setba  except  that  the  value  argument  is  an 
expression. 

The  second  transfer  operator  is  fcsef  and  is  defined  by 

(T2)  T[tcset](u,e)  =  setb(u.adjust(/j ,  it  <o,1)) 
where  /?  =  bconv(e) 

In  this  case,  the  value  is  first  converted  to  a  bitstring,  then  adjusted  using  its  leftmost  bit  as  a 
extension  value,  rather  than  zero  as  in  the  case  of  usset.  By  substituting  the  definition  of 
setba  in  the  definition  of  usset.  one  can  see  precisely  the  difference  in  semantics  of  the  two 
transfer  operators. 

Through  the  use  of  the  setb  and  setba.  the  semantics  of  the.  transfer  operators  specifies  that  the 
order  of  assignment  of  values  to  locations  is  left-to-right.  This  need  not  be  the  case,  of  course.  A 
right-to-left  ordering  or  an  unspecified  ordering  are  two  other  equally  valid  possibilities. 

4.3.8  Structures  (S:Str-»P) 

A  structure  is  used  in  several  places  in  AMDL  Primarily,  it  is  used  to  define  the  bit  or  word 
structure  of  a  variable.  It  also  is  found  in  a  particular  type  of  action,  the  decode  action,  which 
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we  will  look  at  shortly.  Its  semantics  is  simply  a  pair  of  numbers,  corresponding  to  the 
constant(s)  present 

(Kl)  S[(pair  Xj  X2)]  =  <C[X1]i1,C[X2]l1  > 

(K2)  S[X]  =  <C[X]41,C[X]41> 

In  the  case  of  (K2)  where  a  single  constant  is  specified,  the  value  component  is  duplicated.  Note 
that  the  length  component  of  the  constants  is  ignored  in  both  cases. 

4.3. 9  Actions  (A:Act-»U-»G— »C-»C) 

Actions  provide  the  control  structures  for  AMDL.  Like  the  expressions,  their  semantics  is  a 
function  of  an  environment  p.  a  procedure  continuation  y,  and  their  own  continuation.  An 
action  continuation  is  simply  a  function  S-*ANS  from  stores  into  answers.  This  says  that  the 
intermediate  result  of  an  action  is  just  a  new  store,  and  that  actions  do  not  produce  any  other 
values  (as  do  expressions). 

The  first  action  we  will  look  at  is  the  label  action.  Before  we  examine  the  definition,  let  us  first 
consider  what  the  role  of  a  label  is  in  AMDL.  Labels  can  be  referred  to  by  two  operators,  leave 
and  restart,  which  are  used  to  alter  the  otherwise  sequential  course  of  execution.  Briefly,  a 
leave  of  a  labelled  action  is  like  a  "goto"  to  the  end  of  the  action  and  a  restart  is  like  a  "goto" 
to  the  beginning  of  that  action.  In  order  that  these  leave  and  restart  operators  can  function,  a 
pair  of  "jump"  continuations,  one  for  each  operator,  is  placed  in  the  ULAB  (third)  component  of 
the  environment,  which  is  a  function  of  type  lde-*’((JXJ)  +  ©).  where  J  is  the  domain  of  jump 
continuations  with  J  =  C.  Given  an  environment  p,  therefore,  and  label  identifier  I.  then  p43A1 
would  give  the  semantics  of  a  leave  of  that  label  and  p4342  the  semantics  of  a  restart.  We 
are  now  ready  to  examine  the  label  definition. 

(A3)  A[(label  I  A)]py0  = 

A[A]update(p.3,p43[<0.A[(label  I  A)]py0>/I])y0 

The  semantics  of  the  label  action  is  the  semantics  of  the  enclosed  action  A  with  an  updated 
environment  updafe(p,3,p43[<0,A[(label  I  A)]py0>/I]).  The  third  element  of  the 
environment  p.  as  stated  earlier,  is  used  in  conjunction  with  leave  and  restart  actions.  Here, 
the  I  component  of  the  third  element  is  being  replaced  with  the  sequence  '6, A  [(label  1 
A)]py0>.  The  first  element  8  of  this  sequence  is  the  "leave"  component  of  the  list.  That  is  to 
say.  the  semantics  of  a  leave  action  within  the  scope  of  A  will  be  the  semantics  6  of  the  rest  of 
the  program  following  this  label  statement.  The  second  component  A  [(label  I  A)]py0  of  the 
list  is  the  "restart"  component.  This  says  that  the  semantics  of  a  restart  action  within  the  scope 
of  the  action  A  is  the  semantics  of  the  label  action  itself.  This  recursive  definition  is  quite 
natural  when  one  views  the  restart  operator  as  a  "goto"  back  to  the  start  of  the  label  action. 
Note  that  the  both  terms  in  the  sequence  <0,A[(label  I  A)]py0>  are  themselves  action 
continuations,  that  is.  functions  from  a  store  into  an  answer.  This  is  necessary,  of  course,  so  that 
the  store  at  the  time  of  the  restart  or  leave  is  passed  along  to  the  remaining  computation. 
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I"here  is  no  resume  element  in  the  sequence  because  a  resume  of  a  label  is  never  legal. 

The  semantics  of  the  leave,  restart  and  resume  operators  are  now  relatively  straightforward. 
Recall  that  procedure  continuations  y  contain  the  continuations  associated  with  a  leave,  restart 
or  resume  of  procedures  which  are  currently  active.  There  must  be  some  algorithm,  therefore, 
whereby  these  operators  determine  whether  they  refer  to  labels  or  procedures.  Because  resume 
is  not  defined  to  operate  with  respect  to  labels,  it  will  always  refer  to  procedures.  The  operators 
leave  and  restart,  however,  will  refer  to  labels  if  the  label  encloses  the  operator  in  the  current 
procedure.  Only  if  no  such  label  exists,  will  the  leave  and  restart  operators  refer  to 
procedures.  The  semantics,  then,  are  as  follows: 

(A4)  A[(leave  \)]pyd  = 

p43[I]60  — p43[I]41, 

660-*err(7), 

y(641)60-*err(8), 

7(541)41 
where  6  =  p42[I] 

(A5)  ^[(restart  I)]py0  = 

p43[I]$0-»p43[I]42, 

660-*err(  7), 
y(541)60-*err(8), 

7(541)42 
where  5  =  p42[I] 

(A6)  A[( resume  I)]py0  = 

66  0-*err(7), 

y(541)60-»err(8), 

y(641)4360-»err(8), 

7(641)43 
where  6  =  P42[I] 

Both  the  leave  and  restart  definitions  first  check  whether  or  not  there  is  a  valid  label  of  that 
name  by  checking  the  value  of  p43[I],  If  this  value  is  not  undeclared,  then  it  is  a  list  of  two 
continuations  and  the  appropriate  continuation  is  extracted  to  provide  the  semantics  of  the  action. 
If  no  such  label  exists,  then  the  action  must  refer  to  a  procedure.  All  three  definitions  define  6 
to  be  the  procedure  element  of  the  environment  applied  to  the  identifier  I.  If  560.  then  no 
procedure  has  been  associated  with  that  identifier,  and  an  error  has  occurred.  If  660.  however, 
then  641  is  a  location  which  can  be  used  as  an  index  into  y.  If  y(641)60.  then  the  procedure 
is  not  active  and  an  error  has  occurred.  If  the  procedure  is  active,  however,  then  7(6 41)  will  be 
a  triple  of  "jumps"  corresponding  to  leave,  restart  and  resume  of  that  procedure.  Actually, 
the  third  jump  (for  resume)  will  be  undeclared  if  the  procedure  referenced  is  the  current 
procedure,  and  an  error  will  occur.  In  all  other  cases,  however,  the  jump  is  simply  extracted  as 
the  value  of  the  action. 
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It  should  be  noted  that  in  determining  the  procedure  location  fill,  the  emironment  is  consulted, 
while  the  actual  jump  is  obtained  from  the  procedure  continuation  y.  This  means  that  only 
procedures  which  are  statically  accessible  may  be  referenced  by  these  operators.  Procedures 
outside  the  static  scope  of  the  operator  can  never  be  left,  restarted  or  resumed. 

The  call  action  is  very  close  to  the  call  expression,  both  in  syntax  and  semantics.  The  only 
difference  in  syntax  is  that  the  call  expression  contains  a  variable  reference  and  the  call  action 
only  contains  an  identifier.  The  semantics  differ  in  that  the  call  expression  effects  a  reference  to 
the  variable  after  the  procedure  has  been  invoiced,  whereas  the  call  action  does  not.  The 
equation  is 

(A10)  £[(call  I  Ej  E2  ...  En>Q)]py0a^  = 

5€0  — err2(  9), 

542*n-*err2(10), 
y(64.1)€0  — e/Y2(17), 

,E[E2]py{Ae2-  £[En]py 

{^enffl(^1)(eve2 . en^Ti)  })<*! 

where  S  =  PA2[I] 

Yj  =  y[upc/afe(y(pi4),3,j)/p'f4][<j.©,®>/611] 

\  =  e 

n  is  the  subscript  of  En 

if  n  =  0.  then  the  last  clause  in  the  equation  reduces  to 
a(5;i)(<>)Yl 

Note  that  the  main  difference  in  this  equation  and  (F.4)  for  the  call  expression  is  in  the 
definition  of  j.  In  this  case,  j  is  simplj  the  continuation  of  the  action  itself. 

The  semantics  of  the  repeat  and  seq  is  straightforward.  The  equations  are 

(A7)  A[(repeat  A)]py0  = 

A[A]py{A[(repeat  A)]py0} 

(A8)  A[(seq  Aj  A2  ...  An)]py0  = 

^lAjJpyf 4[A2]py  ...  {A[An]py0}  ...  } 

The  first  equation  says  simply  that  the  semantics  of  repeat  is  the  semantics  of  the  enclosed 
action  with  a  continuation  equal  to  the  semantics  of  the  repeat  itself.  The  situation  here  is 
identical  to  constructing  the  restart  component  in  the  label  action.  This  is  reasonable,  as  a 
repeat  is  equivalent  to  a  label  with  a  restart  as  the  last  embedded  action.  The  semantics  of 
seq  shows  a  nested  set  of  continuations  producing  the  sequential  execution  of  the  indhidual 
actions. 

The  par  action  is  supposed  to  indicate  parallel  execution  of  a  set  of  actions.  We  have  not 
worked  out  the  details  of  this  semantics,  however,  so  for  the  moment  the  semantics  is  identical  to 


42 


the  semantics  of  the  seq  action. 


(A9)  A[(par  A}  A2  ...  A n)]pytf  = 

Al^]py{A[K2]py  ...  {A[An]py0}  ...  } 

The  cond  action  is  like  a  limited  McCarthy  conditional.  Its  semantics  is 

(Al)  A[(cond  (E  X))]py6  =  £[E]pY{Ae.ei1  *O-*A[A]p-y0,0} 

The  expression  E  is  evaluated  with  a  continuation  which  either  evaluates  the  action  A  (if  the 
value  part  of  the  result  of  the  expression  is  non-zero)  or  is  the  normal  continuation  6. 

Since  expressions  are  also  legal  actions,  the  semantics  of  an  "expression"  action  is  given  by 
(All)  A[E]py0  =  £[E]py{Ae.l9} 

The  fact  that  the  expression  value  produced  by  F[E]  is  ignored  is  obvious  from  the  continuation 
{Xe.0}. 

The  next  action  we  consider  is  the  write  action.  This  action  evaluates  an  expression  and 
concatenates  the  value  of  the  expression  with  the  answer  produced  by  the  rest  of  the  program. 
Its  definition  is  one  of  the  two  (the  other  being  the  definition  for  err)  where  the  elements  from 
the  answer  domain  ANS  are  actually  manipulated.  The  equation  is 

(A12)  A[(write  E)]py0  =  £[E]py{\eCT.<e41  in  OUT>§0(o)} 

The  expression  E  is  evaluated  with  a  continuation  {Aea.<e>11  >§0(a)}  which  specifies  how  the 
result  is  combined  with  the  answer  produced  by  the  rest  of  the  program.  Normally,  expression 
continuations  arc  written  as  {Xe.  ...  }  where  the  body  of  the  lambda  expression  is  some  function 
in  S-*ANS.  In  the  above  continuation,  however,  we  need  to  specify  the  store  a  on  the  left-hand 
side  of  the  lambda  expression,  because  it  must  be  referenced  explicitly  in  the  body.  In  the  body, 
the  action  continuation  8  is  applied  to  the  current  store  <7  to  produce  an  answer.  This  answer  is 
then  appended  to  the  value  portion  e41  of  the  the  expression  evaluation  to  produce  the  new 
answer  <e41  in  OUT>§0(ct). 

The  decode  action  is  the  final  action  in  AMDL.  This  action  has  been  left  until  last  because  it 
contains  a  rather  complicated  component  part,  called  a  decode  clause.  A  decode  statement  is 
similar  to  a  select  or  case  statement  in  other  languages.  The  syntax  consists  of  an  expression  and 
a  list  of  decode  clauses.  The  expression  is  first  evaluated,  and  then  the  decode  clauses  are 
analyzed  until  one  of  them  "succeeds."  If  none  of  the  decode  clauses  succeeds,  then  the  action  is 
in  error.  The  equation  looks  like 

(A2)  ^[(decode  E  (Zj  Z2  ...  Zn))]pyfl  = 

E[ E]PY{Xe.Z[Z1](e*l)(0){Z[Z2](el1)(1)  ... 

{Z[Zn](eAn)(n1){err(16)}py0}  ...  py8)py8) 

It's  rather  hard  to  understand  the  semantics  of  the  decode  action  without  understanding  the 
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semantics  of  the  decode  clause,  but  the  reverse  situation  is  difficult  as  well.  What  the  above 
equation  says  is  that  the  expression  E  is  evaluated  with  a  continuation  that  contains  the  evaluation 
of  the  first  decode  clause.  The  arguments  to  that  first  decode  clause  arc  the  result  ell  of 
evaluating  the  expression  E.  the  integer  index  of  the  decode  clause  in  the  decode  action,  a 
continuation  {Z[ Z2]  ...  }  which  will  be  evaluated  if  the  decode  clause  fails,  and  the  standard  py8 
which  provides  the  environment,  procedure  continuation  and  action  continuation.  The  action 
continuation  6  is  used  if  the  decode  clause  succeeds.  Note  that  the  failure  continuation  passed  to 
the  final  decode  clause  is  (err(16)}  which  causes  the  action  to  fail  if  evaluated.  If  it  was  ever 
decided  to  change  the  semantics  of  an  unsuccessful  decode  to  a  no-op.  this  failure  continuation 
could  simply  be  replaced  by  8. 

4.3.10  Decode  Clauses  (Z:Dcl-»N-*N-»C-»U-»G->C) 

With  the  semantics  of  the  decode  action  fresh  in  our  memory,  let'sexaminc  the  semantics  of  the 
decode  clause.  There  are  three  types  of  decode  clauses  which  differ  in  how  they  specify  their 
"triggering"  values.  The  first  type  of  decode  clause  is  always  satisfied.  Its  semantics  is 

(Z4)  Z[(otherwise  A)]nm0  =  A[A] 

The  semantics  is  independent  of  tire  expression  result  n.  the  position  m,  and  the  failure 
continuation  0.  The  action  A  is  always  evaluated  and  is  passed  the  success  continuation.  The 
above  notation  is  an  extreme  example  of  how  currying  reduces  the  size  of  an  equation. 

The  second  decode  clause  we  will  examine  specifies  the  triggering  values  by  means  of  a  single 
structure  2.  Its  semantics  is 

(Z2)  Z[(2  A)]nm0lPY02  = 

S[2]41<n<S[2]42—A[A]pY0y 

If  the  value  of  n  lies  in  the  closed  interval  defined  by  the  number  pair  S[2],  then  the  decode 
clause  has  "succeeded"  and  the  action  A  is  evaluated.  Otherwise,  the  failure  continuation  8  j  is 
taken. 

The  third  type  of  decode  clause  is  similar  to  that  in  (Z2)  above,  except  that  rather  than  specifying 
a  single  structure,  a  list  of  structures  is  given.  In  this  case,  the  decode  clause  succeeds  if  the 
expression  value  falls  within  the  closed  interval  defined  by  any  of  the  structures.  The  semantic 
equation  is 

(Zl)  Z[((2j  22  -  2n>  A)]nm0jpY02  = 

(S[21]4l<n<S[21]A2)V(S[22]41<n<S[22]4.2)V  ...  V 
(S[£n]41<n<S[2n]i2)-A"[A]pY(?2 

«1 

None  of  the  prev  ious  three  types  of  decode  clauses  has  utilized  the  "index"  argument  m  of  the 


decode  clause  function.  The  final  type  of  decode  clause  uses  this  value  as  an  implicit  structure 
with  which  to  compare  the  expression  value.  The  semantics  is 


(Z3)  Z[A]nm0^pY02  = 

n  =  m-»A[A]pY#T 

«1 

Note  that  the  term  n  =  m  was  used  instead  of  the  equivalent  comparison  m<n<m. 
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4.3.11  Variables  (P:Var-»N  —  X-»X,  PO  :Var-*N  —  U  — 0-*O) 


Variables  are  used  within  declarations.  They  may  stand  alone,  in  which  case  they  act  as  their  own 
declaration.  They  may  also  occur  within  a  procedure  declaration  or  an  overlap  statement.  The 
semantics  for  variables  must  be  general  enough  to  handle  each  of  these  cases. 

Before  we  can  proceed  further,  we  need  to  introduce  yet  another  continuation,  the  declaration 
continuation.  This  is  a  function  x:X  =  Q-»U-»C,  where  0  is  a  domain  of  local  binding  functions. 
U  is  the  domain  of  environments,  and  C  contains  our  familiar  action  continuations.  Recall  from 
Section  4.2.5  that  q€Q  is  a  function  which  keeps  track  of  which  identifiers  have  been  declared 
within  the  current  context.  The  meaning  of  a  variable  is  to  take  a  binding  function  q.  an 
environment  p.  a  store  a  and  a  declaration  continuation  x  and  apply  that  declaration 
continuation  to  updated  q,  p  and  a.  The  semantic  domain  for  Var  could  then  be  written  as 
P:Var-»(QXUXSXX)-»ANS.  But  by  rearranging  the  parameters  and  currying,  we  can  obtain 
P:Var-»X-»X.  The  extra  parameter  N  seen  above  is  used  to  distinguish  between  the  various 
contexts  in  which  the  variable  occurs.  The  other  semantic  domain  PO  deals  specifically  with 
overlays  and  will  be  discussed  later. 

We  also  need  to  introduce  two  support  functions  new  and  get  which  allows  us  to  allocate  new 
locations  from  a  store,  new  is  defined  simply  by 

(SF12)  new:S-*L  Gets  new  location  from  an  S 

new(o)  = 

I  such  that  ct(I)  =  © 

For  a  given  store  a.  therefore.  new{a)  yields  an  '  unused"  location  in  a.  The  function  get  is 
simlar  to  new.  except  that  get  is  used  to  obtain  a  sequence  of  unused  locations  from  a  store.  It 
is  defined  as 

(SF9)  gef:(NXS)-»L  Gets  a  sequence  of  locations  from  an  S 

ge/(n,a)  = 

n  =  l-»<new(a)>. 

< new(ff)>§gef(n  -  1  ,a[0/nenv(a)]) 
for  n>1 

Let  us  look  at  the  semantics  of  the  simple  variable. 

(P3)  P[(bits  I  2)]nxqpaj  = 
q[I]  =true-»err2(13), 

xq[true/I]updafe(upda/e<p,1,p41[<w.S[Z]>/I]),2.p42[©/I])CT2 

where  u  =  (n  =  2-*©,gef(n1,cj)) 

oj  =  (n  =  2-»<jj,sefba(w,<0>)CTj) 
n1  =  s/ze(S[2]) 
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First,  the  function  q  is  applied  to  the  identifier  1.  If  1  has  been  previously  declared,  then  an  error 
has  occurred.  If  this  is  not  the  case,  then  the  declaration  continuation  x  is  applied  to  an  updated 
q.  p  and  a.  The  updated  q  is  simply  the  same  q  with  q[I]  defined  to  be  true.  The  new  p  has 
updated  entries  in  the  first  and  second  components,  corresponding  to  a  new  meaning  for  "I"  as  a 
variable  and  a  procedure.  The  procedure  component  is  updated  with  the  undeclared  element.  ©. 
(In  the  case  where  this  variable  is  nested  within  a  procedure  declaration,  this  entry  will  later  be 
replaced.)  The  variable  component  of  the  environment  and  the  new  store  depend  on  the 
argument  n  defining  the  context  in  which  the  variable  occurs. 

There  are  three  possible  values  for  n.  with  meanings  that  are  given  below. 

0  Variable  occurs  by  itself 

1  Variable  occurs  within  proc  declaration 

2  Variable  occurs  within  over  declaration 

In  the  definition  we  are  currently  examining,  a  distinction  is  made  between  n  =  2  and  n*2.  In 

both  cases  the  structure  S[2]  of  the  variable  is  placed  in  the  appropriate  field  of  the  variable 
entry.  The  location  string  <a.  however,  depends  on  the  value  of  n.  If  n  is  not  equal  to  2.  then 
unused  locations  are  obtained  from  the  store  cr  and  used  for  w.  If  n  is  2.  then  the  location  string 
in  the  variable  entry  for  "I"  is  set  to  the  undeclared  element.  This  is  due  to  the  fact  that  in  over 
declarations,  no  new  locations  are  implied:  variables  are  simply  mapped  onto  existing  locations. 
Ihe  new  store  aj  is  simply  the  old  store  aj.  in  the  case  of  the  overlay.  When  new  locations  have 
been  obtained  from  the  store,  however,  these  locations  must  be  mapped  into  something  other 
than  ®  to  avoid  their  possible  re-use.  This  is  done  with  sefba(ca,<0>)aj.  in  the  case  of  n*2. 

The  next  type  of  variable  we  will  look  at  is  the  array  variable.  Its  semantics  is  quite  similar, 
except  for  the  complications  introduced  by  the  additional  dimension.  In  order  to  deal  with  this 
added  dimension,  we  need  to  introduce  another  two  support  functions,  size  and  reshape. 


They  are  defined  by 

(SF19) 

size:P-»N 

Gives  "size"  of  a  P 

s/ze(p)  =  abs(p!1-pl2)  +  1 

(SF16) 

reshape:(NXW)  — A 

reshaped, u)  = 

Reshapes  a  W  into  an  A 

<<a!1.al2 . aim), 

<wl  (m  +  1),a>l(m  +  2) . o)l(2*m)>, 

<o)l((n-1)*m  +  1),o)l((n-1  )*m  +  2) . o)l(n*m)>> 

where  m  =  ( #  o>)/n 

for  n>1  and  (#o>  mod  n)  =  0 

size  is  used  to  yield  the  number  of  elements  implied  by  a  particular  indexing  pair.  For  example. 
size(< 0,7>)  =  8.  reshape  is  similar  to  the  dyadic  APL  reshape  operator  p.  Given  a  string  u 
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and  a  nonnegaii\e  integer  n.  it  yields  a  sequence  of  n  elements,  each  element  containing 
successive  #to/n  elements  from  u>. 

Looking  at  the  definition  for  array  variable  declarations,  then,  we  have 

(PI)  P[(words  (bits  I  2j)  2->)]nxqpaj  = 
q[I]  =  true-+e/r2(2), 

Xq[true/I]updafe(updafe(p,1  ,p41[<a.S[2i].S[2N]>/I]).2.pi2[@/I])oi 
where  a  =  (n  =  2-*©,res/)ape(s/ze(S[21j]),to)) 
cti  =  (n  =  2— ►a^,sefba(io,<0>)a[) 
u  =  gef(m.a  j) 

m  =  s/'ze(S[21])*s/'ze(S(S2]) 

The  major  difference  in  this  equation  is  in  the  definition  of  the  location  string  to  and  in  the  fact 
that  both  the  word  and  bit  structure  of  the  variable  are  placed  in  the  environment.  The  string  to 
is  first  formed  by  obtaining  the  appropriate  number  of  locations  from  the  old  store.  This  string  is 
then  shaped  into  an  array  location  string,  using  the  reshape  function.  As  before,  the  locations 
obtained  must  be  marked  as  used  in  the  new  store. 

The  next  variable  type  consists  solely  of  an  identifier  "I".  Its  semantics  are 

(P4)  P[I]nxqp  = 

q[I]  =  true->err(2), 
n*  1  —err(3). 

Xq[true/I]updafe(updafe(p,1  ,pl1[©/IJ),2.p4  2[©/t]J 

As  in  (PI)  and  (P3)  above,  the  value  of  q[I]  is  checked.  Unlefs  the  variable  occurs  within  a 
procedure  declaration  (n  =  1).  an  error  has  occurred.  This  is  due  to  the  fact  that  in  the  case  of 
the  variable  declaration  or  the  overlay,  the  purpose  of  the  variable  is  to  define  a  new  storage 
entity.  Without  any  structure  components,  the  variable  cannot  be  properly  defined.  Note  that 
the  language  could  have  defined  a  default  bit  structure  for  this  case,  in  which  case  the  definition 
would  have  appeared  similar  to  definition  (P3)  for  simple  bit  structured  variables.  If  the  variable 
occurs  within  a  procedure  declaration,  however,  the  identifier  will  have  some  purpose,  that  of 
denoting  the  procedure  associated  with  it.  In  that  case,  the  environment  is  simply  updated  with 
the  undeclared  element  ©  in  both  the  variable  and  procedure  components. 

The  remaining  variable  type  is  always  an  error  when  it  occurs  as  a  declaration.  This  is  the  case 
where  a  word  structure  is  given  without  an  accompanying  bit  structure.  The  semantics  is  simply 

(P2)  P[(words  I  2)]nxqp  =  err(3) 

We  now  come  to  the  semantic  function  PO.  As  was  said  earlier,  this  function  is  used  solely  in 
conjunction  with  the  overlay  construct.  The  syntax  of  an  overlay  is  quite  general.  A  new 
variable  is  somehow  equated  with  a  list  of  previously  defined  variables,  there  are.  of  course, 
many  possible  interpretations  of  this  general  mechanism.  The  interpretation  we  have  chosen  may 
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not  coincide  with  the  reader's  intuitive  notion.  It  senes  to  show,  however,  that  even  the  most 
complicated  of  interpretations  can  be  precisely  specified  by  this  definitional  method. 

The  basic  idea  behind  our  interpretation  of  the  overtax  is  that  the  location  strings  associated  with 
the  previously  defined  variables  are  individually reshaped  to  coincide  with  the  length  of  the  new 
variable.  These  reshaped  strings  are  then  row-wise  concatenated  to  form  a  new  structure  which 
must  match  exactly  the  dimensions  of  the  new  variable. 

An  example  is  in  order.  Consider  the  following  collection  of  AMDI.  declarations 

(bits  oldl  (pair  3  0)) 

(bits  (words  old2  (pair  0  5))  (pair  1  0)) 

(bits  (words  old3  (pair  0  1))  (pair  1  0)) 

(over  (words  new  (pair  0  3))  (pair  4  0)  (a  b  c) 

or  the  equivalent  ISPS  declarations 

old  1  <3:0>, 

old2[0:5]<1:0>, 

old3[0:1]<1:0>, 

new:  =  oldl  @old2@old3 

Then  the  following  figure  shows  that  the  locations  associated  with  the  variables  oldl,  old2  and 
old3  are  combined  together  to  define  the  variable  new. 
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In  this  case  a  4  by  5  array  is  being  defined  as  the  concatenation  of  a  4  bit  word,  a  6  by  2  array 
and  a  2  by  2  array.  Note  that  the  locations  for  each  of  the  variables  oldl.  old2  and  old3  fit 
exactly  into  one  or  more  columns  of  the  left  hand  side.  This  is  a  requirement  of  all  overlays. 
Note  that  if  this  rule  is  obeyed  and  the  total  number  of  locations  in  the  defining  expression  is 
equal  to  the  number  of  locations  required  for  the  new  variable,  then  the  resulting  array  obtained 
from  concatenating  the  arrays  in  the  defining  expression  will  always  have  a  word  length  equal  to 
that  of  the  new  variable.  This  is.  in  fact,  the  algorithm  used  to  check  the  legality  of  an  overlay  in 
the  ensuing  definitions. 

The  formal  definition  of  overlays  is  split  between  the  definition  of  PO  and  the  definition  of 
declarations.  The  function  PO.  with  which  we  are  now'  concerned,  is  applied  only  to  variables  in 
the  defining  expression  of  an  overlay.  Given  the  length  of  the  new  variable,  the  intermediate 
result  of  PO  is  an  array  location  string  reshaped  to  that  given  length.  We  introduce  the  overlay 
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continuation  o:0  =  A-»ANS  which  accepts  this  reshaped  string  as  its  argument.  We  must  use  a 
continuation,  because  an  error  may  be  discovered  within  PO.  In  particular,  a  variable  in  the 
defining  expression  might  not  reshape  evenly  into  the  given  length. 

As  we  have  seen,  there  are  four  variable  types  to  be  examined.  Rather  than  starting  with  the 
simplest  case,  we  will  first  treat  the  most  difficult  one.  Once  this  definition  is  understood, 
however,  the  other  cases  will  follow  easily  from  it.  First,  however,  we  must  define  another 
support  function,  aconc.  aconc  yields  the  row-wise  concatenation  of  two  array  location  strings 
and  is  defined  as  follows. 

(SF2)  aconc:(AXA)-*A  Row  concatenation  of  two  As 

aconc(a  j.ai)  = 

§a-)A1 , a j!2§a-)i2 . aj4(# aj)§a2'f(#  on)) 

for  it  aj  =  tt  aj 

Examining  (POl).  then  we  have 

(POl)  PO[(words  (bits  I  2j)  22)]npoa  = 

6€ARRAY-*err2(5), 

-'(/ega/(S[21].542)A/ega/{S[22].S43))— err2(5), 
(s/ze(S[21])*s/ze(S[22])  mod  n)*0-*err2(6), 
o(aconc(a,res/jape(n,<ap;i§topJ,1 +1§  ...  §wpi2))) 
where  5  =  p 4- 1  [I] 

=  exfracf(norm(S[2j],5t2),64Hi) 
p  =  no/7n(S[22].S43) 

The  first  thing  that  must  be  true  is  that  the  identifier  referenced  corresponds  to  an  array  variable. 
Second,  the  structures  2j  and  22  must  be  legal  references.  Third,  the  number  of  bits  in  the 
referenced  portion  of  the  variable,  computed  by  s/ze(S[21])*s/ze(S[22])-  must  be  an  even 
multiple  of  the  new  variable  length  n.  If  all  this  is  true,  then  the  overlay  continuation  o  is 
applied  to  the  concatenation  of  the  existing  array  location  string  a  and  the  reshaped  structure. 
This  reshaping  is  done  by  first  concatenating  together  the  appropriate  bitstrings  in  the  appropriate 
words.  The  appropriate  bitstrings  are  found  by  Wj  =  exfrac/(nom?(S[21],542).541 4i).  The 
range  of  words  referenced  is  given  by  p  =  norm(S[27], 543). 

The  next  variable  type  specifies  a  word  range  but  does  not  give  a  bit  range.  Its  semantics  is: 

(P02)  PO[(words  I  2)]npoa  = 

6€  ARRAY-*  err2(5), 

~i  legal(S  [  2]  ,6  4  3)  -*  err2(  5) , 

(s/ze(542)*s/ze(S[2])  mod  n)*0-*err2(6), 
o(aconc(a,res/iape(n,wp|1§wpi1 +1§  ...  §wpi2))) 
where  5=p41[I] 

<jj  =  541 4i 

p  =  rrorm(S[2],S43) 
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This  definition  is  identical  to  the  previous  definition,  with  the  exception  that  instead  of  using  a 
user-provided  structure  2  for  the  bit  reference,  the  full  bit  range  is  assumed.  The  equation 
Wj  =  ex/racf(norm(S[2j].642),6'H 4i)  then  becomes  wj  =  exfracf(norm(S42,542),54  1  4i). 
which  further  reduces  to  the  above  co,  =  5T1 4i. 

The  next  variable  type  specifies  a  bit  range  but  not  a  word  range.  Unlike  the  previous  two  types, 
this  reference  can  refer  to  a  word  variable  or  an  array  variable.  These  two  cases  are  distinguished 
in  the  definition  below. 

(P03)  PO[(bits  I  Z)]npoa  = 

8€0-»err2(  5), 

—i  legal{S  [2]  ,64-2) — ►  err2(  5), 

S6WORD-* 

(s/ze(S[2])  mod  n)*0-»err2(6), 

o(aconc(a,res/7ape(n,ex/racf(norm(S[2],S42),S41)))) 

5€ARRAY— 

(s/'ze(S[2])*s/'ze(643)  mod  n)*0-*err2(6), 
o(aconc(a,reshape(n,wp|1  §w^p|1  j  +  1  §  ...  §wpi2))) 
where  5  =  p41[I] 

Wj  =  exfracf(nomj(S[2],S42),841 4i) 
p  =  norm(8l3,8i3,  =  <1.s/'ze(643)> 

In  the  case  that  the  variable  is  an  array  variable,  the  definition  is  similar  to  the  first  definition. 
The  only  difference  is  that  instead  of  using  a  user-supplied  word  range,  the  entire  word  range  is 
assumed.  If  the  variable  is  a  word  variable,  then  the  appropriate  locations  are  extracted  from  the 
w'ord  location  string  541  and  are  reshaped  and  passed  to  the  overlay  continuation  as  usual. 

The  final  variable  type  specifies  neither  a  bit  range  nor  a  word  range.  Its  definition  is  identical  to 
the  previous  definition,  except  that  both  ranges  are  defaulted  to  their  full  value. 

(P04)  PO[I]npoa  = 

6€0-*err2(5), 

-i  legal(S[Z ]  ,8  42)-  err2(5), 

SUWORD— 

(s/ze(542)  mod  n)*0-*err2(6), 
o(aconc(a,  reshape(n,6  4 1 ))) 

8CARRAY— 

(s/ze(642)*s/ze(S43)  mod  n)*0-*err2(6), 
o(aconc(a,reshape(n,Wp|i§wpAi  +  -|§  ...  §wp|2))) 
where  5  =  p41[I] 

Wj  =  S4l4i 

p  =  norm(8  43,6  43)  =  <1,s/ze(643)> 
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4.3.12  Declarations  (D: Dec-»X-»X.  DP.Dec->\J-»C-*C) 

The  semantics  of  declarations  is  among  the  most  complicated  in  AMDL.  There  are  actually  two 
semantic  functions.  D  and  DP.  The  first.  D.  can  be  thought  of  as  the  "top-level"  semantic 
function.  The  second.  DP.  is  required  for  the  semantics  of  the  proc  declaration.  We  will 
consider  the  top  level  function  first. 

The  domain  for  D  is  the  same  as  for  the  function  P  which  we  ha\e  already  examined.  Gi\en  a 
binding  function  q.  an  environment  p,  a  store  a  and  a  declaration  continuation  x-  it  produces  an 
answer  by  applying  the  declaration  continuation  to  an  updated  binding  function,  environment  and 
store.  The  simplest  type  of  declaration  has  the  simplest  semantics,  as  follows: 

(D3)  D[n]  =P[n](0) 

Here  we  see  that  the  meaning  of  the  declaration  is  simply  P[n]  with  an  argument  of  ”0"  which 
denotes  that  the  variable  occurs  by  itself.  This  is  another  example  of  how  currying  reduces  the 
size  of  these  equations. 

The  next  type  of  declaration,  the  overlay,  is  not  quite  as  simple.  We  have  already  looked  at  the 
most  complicated  part  of  the  semantics,  however,  in  our  examination  of  PO.  The  definition  is 

(D2)  D[(over  n0  (n}  n2  ...  nn»]x  = 

P[n0](2){Aqpa.POtn1]np{PO[n2]np  ...  {PO[nn]npo}  ...  }<>} 
where  o  =  {Aa.  it  (ai1)*s/ze(SI2)-»e/7-2(12), 

XPPl®} 

n  =  (6€ARRAY-»s/ze(6A3), 

5  =  pl1(P/[n0]) 

Pl  =  updafefp,  1, pi  l[updafe(5.1.(6€  ARRAY -►a. a  ■H))/P/[n0]]) 

First,  the  variable  FIq  is  evaluated  with  an  argument  of  2.  showing  that  the  variable  is  being 
defined  in  an  overlay  declaration.  The  continuation  passed  to  P  then  applies  PO  to  each  of  the 
variables  in  the  defining  expression,  passing  to  them  the  updated  p  and  the  new  variable  length 
n.  The  length  n  is  determined  by  examining  the  updated  p  and  examining  the  variable's  newly 
defined  structure.  If  it  is  a  word  variable,  the  length  n  is  simply  1.  If  it  is  an  array,  then  the 
length  is  found  by  taking  s/ze(6l 3)  where  6  =  pl1(P/[riQ]). 

The  concatentation  of  the  array  location  strings  is  accomplished  by  supplying  each  application  of 
PO  w  ith  a  continuation  consisting  of  an  application  of  PO  to  the  next  variable.  Note  again  how 
the  currying  has  allowed  us  to  perform  this  concatenation  concisely.  The  partial  application  of 
PO  provides  us  with  a  declaration  continuation  without  the  need  to  form  a  lambda  expresion. 
The  <>  appearing  just  inside  the  rightmost  "}"  is  an  empty  array  location  string  which  is  passed 
to  PO^]  to  initialize  things. 

The  declaration  continuation  o  performs  some  final  checking  and  then  applies  the  original 
declaration  continuation  x  to  the  updated  results.  The  check  is  that  the  w  ord  size  of  the  resulting 
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array  location  string  a  is  equal  to  the  word  size  of  the  new  variable.  This,  in  addition  to  the 
in\ idual  checks  occurring  in  PO.  assures  that  the  total  number  of  locations  required  by  the  new 
variable  equals  the  total  number  of  locations  in  the  defining  expression.  The  binding  function  q 
and  the  store  a  passed  to  the  declaration  continuation  are  the  same  q  and  a  which  were  passed 
from  pIIIq].  A  new  environment  p3.  howexer.  includes  the  definition  for  the  new  variable.  If  it 
is  an  arrax  xariable.  then  the  array  location  string  a  is  simply  used  as  the  defining  location  string. 
If  it  is  a  word  variable,  then  one  layer  of  structure  must  be  removed  from  a  which  is  always 
formed  as  an  array  location  string,  a  w  ill  contain  exactly  one  location  string,  in  this  case,  and  this 
one  string  is  referenced  simply  by  all. 

We  now  examine  the  procedure  declaration.  The  following  definition  is  incomplete.  The 
function  DP  provides  the  majority  of  the  semantics  for  procedures. 

(Dl)  D[(proc  n0  aij  n2  ...  nn)  Aj  a2  ...  Am  A)]X  = 

ptn0](l){Xqp<z.x(q)(upcfafe(p,2,pl2[<l.n>/P/[no]]))ff[0/l]} 
where  n  is  the  subscript  in  I"In 
I  =  new(a) 

The  operation  performed  by  this  function  is  to  declare  the  identifier,  through  the  application  of 
PI  n0]  and  to  then  place  a  new  location  I  and  the  number  of  procedure  arguments  n  in  the 
function  component  of  the  environment.  The  location  I  will  later  be  used  as  a  pointer  to  the 
denotation  of  the  procedure  body.  The  number  n  is  used  as  a  check  to  insure  that  the  number  of 
actual  parameters  matches  the  number  of  formal  parameters  when  evaluating  call  expressions. 
The  store  a  is  updated  to  reflect  the  fact  that  the  location  I  is  no  longer  available. 

We  now  come  to  the  function  DP.  As  mentioned  earlier,  this  function  performs  the  heart  of  the 
operations  for  defining  procedures.  The  function  takes  an  environment,  a  store,  and  an  action 
continuation  and  produces  an  answer.  The  definition  is  quite  involved  and  we  will  have  to 
examine  it  carefully. 

(DPI)  DP[( proc  n0  (rij  n2  ...  nn)  Aj  a2  ...  Am  A)]Pl<?1  = 
ptni]o{Ptn2]o  ...  {p[un]Oxl}}Q^plel 
where  q^XI.® 

Xl  =  {D[A1]{D[A2]  ...  {D[Am]X2}}} 

X2={Aq2P2.DP[Ai]p2{DP[A2]p2  ...  {Op[Am]p20 2}}} 

0  2  = 

i  =  pi2(p/[n0])ii 

f  =  X(e1,e2 . en)T2-xrx2°  -  0*r\°el 

6}  =  A  [A]p3Y2[updafe<Y(l),2,0  3)/l]{y(l)  i  1 } 
xj  =  setba(pl‘\(Pl[ni])i-\,ei) 
p3  =  update(pA.\ ) 

and  "°"  denotes  functional  composition 
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The  content  of  the  definition  can  be  summarized  as  follows: 

1.  Declare  the  procedure  arguments. 

2.  Declare  the  internal  definitions. 

3.  Place  the  denotation  of  the  procedure  action  in  the  store. 

4.  Apply  the  action  continuation  6  to  the  updated  store. 

The  procedure  arguments  are  evaluated  with  P  as  if  they  were  simple  variable  declarations.  The 
binding  function  q1  =AI.®  is  a  constant  to  show  that  no  identifiers  have  been  declared  yet. 
Then  the  internal  declarations  are  evaluated  (shown  as  xi )  using  the  function  D.  Recall  that  for 
procedure  declarations,  D  simply  declares  the  identifier  to  be  a  procedure  and  establishes  its 
number  of  arguments  and  location.  D  does  not  add  to  the  environment  the  declarations  which 
are  internal  to  a  procedure.  In  this  way.  after  applying  D  to  all  of  the  declarations  Aj  A->  ...  Am, 
the  correct  environment  has  been  established  for  the  further  evaluation  of  the  declarations 
internal  to  the  A's  and  the  evaluation  of  A  locally.  This  is  done  by  passing  the  continuation  xi 
to  the  final  D[Am], 

X2  applies  DP  itself  to  each  of  the  A's.  Note  that  each  call  to  DP  uses  the  same  environment  p-> 
as  an  argument.  This  makes  sense,  as  the  declarations  local  to  (say)  Aj  do  not  affect  A->.  The 
new  stores  produced  by  DP  are  passed  along,  however,  through  the  nesting  of  the  continuations. 
The  continuation  6 ->  is  the  final  step  in  the  process.  It  applies  the  original  continuation  to  the 
new  store  produced  by  placing  the  denotation  f  of  A  in  the  store  location  I. 

But  what  is  this  f?  Well,  first  of  all.  it  is  a  function  of  n  expression  values.  Second,  it  takes  a 
procedure  continuation  containing,  as  you  recall,  the  return  addresses  or  "rest  of  program"s  for 
previously  invoked  procedures.  The  body  of  f  consists  of  the  functional  composition  of  several 
components.  The  Xj  are  store- to-store  functions  which  place  the  expression  values  passed  in  the 
locations  associated  with  the  formal  parameters.  This  indicates  that  AMDL  uses  a  call-by-value 
convention  for  passing  of  parameters.  After  this  is  accomplished,  the  continuation  6 3  is  applied 
to  the  resultant  store.  6 3  is  defined  to  be  A  [A]  applied  to  the  environment  py  an  updated 
procedure  continuation  yj.  and  an  unusual  action  continuation  {>2(041}. 

The  environment  P3  is  just  the  environment  p 2  with  the  last  component  set  to  the  location  I 
associated  with  the  current  procedure.  How  is  the  procedure  continuation  >->  updated?  Recall 
that  the  entries  in  y  are  a  triple  of  jumps,  corresponding  to  the  leave,  restart  and  resume 
operations  for  the  associated  procedure.  The  second  (restart)  component  of  the  entry  for  the 
current  procedure  (pointed  to  by  I)  is  set  to  be  6 3  itself.  An  ensuing  restart,  then,  will  cause 
the  action  A  to  be  re-evaluated.  Note  that  this  is  not  the  same  as  restarting  f,  for  the  actual 
parameters  to  the  procedure  are  not  reassigned  to  the  formal  parameters. 

The  unusual  continuation  {>2(041}  is  simply  the  leave  component  of  the  current  procedure 
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■  entry,  established  by  the  calling  procedure  at  the  time  of  call.  In  other  words,  an  implicit  leave 

operation  is  performed  after  the  last  statement  in  any  procedure. 

The  definition  of  DP  for  the  other  two  types  of  declarations  are  (mercifully)  quite  simple.  Since  ' 

DP  is  used  only  for  a  "second-pass"  over  procedure  declarations,  the  semantics  in  the  following 
two  instances  is  to  simply  pass  along  the  action  continuation  8. 

(DP2)  DP[(over  nQ  (Ilj  fh  ...  rin))]p0  =  0 

(DP3)  OP[no]p0  =  0 

4.3.13  Programs  (PROG  :Dec-*  AIMS) 

An  AMDL  program  is  syntactically  just  a  declaration.  (We  shall  soon  see  that  this  is  further 
limited  to  only  procedure  declarations.)  But  what  is  the  meaning  of  an  AMDL  program?  From 
the  above  it  would  appear  that  it  is  just  a  constant,  some  member  of  ANS.  This  turns  out  to  be 
quite  sensible  in  that  we  have  included  no  wav  to  accept  any  input  to  the  program.  Let  us  look 
at  how  this  constant  is  derived. 

(PROG1)  PROG  [A]  = 

n*0-»err2(20), 

|  O[A]{Aqp.DP[A]p0}qopoao 

'  where  A  =  (proc  nQ  (FIj  I"I2  ...  nn)  Aj  A2  ...  Am  A) 

n  is  the  subscript  in  nn 

q0={M-©} 

pg  =  <{\I.©},{AI.©},{\L©},©> 
ffO  =  {M-©} 

0  =  {Xa1.a1(l1)(O)Y1a1) 

I1=(p42[n0])l1 

y1  =  YO[<0o.©.©>/l1] 

70  =  {AI.©} 

0o={\a.<>} 

We  check,  first  of  all.  that  there  are  no  parameters  to  the  procedure.  We  then  apply  the 
declaration  function  D  to  the  procedure  with  an  initial  binding  function  q0.  environment  pg  and 
store  ffg-  The  continuation  to  D  then  applies  DP  to  the  new  environment  (now1  containing  the 
entry  for  A)  and  a  continuation  8.  6  extracts  the  procedure  abstraction  for  A  by  using  the 

environment  p  to  determine  the  location  I.,.  This  I-,  then  indexes  into  a  j  to  obtain  the  procedure 
abstraction.  We  know  that  this  procedure  abstraction  takes  no  expression  value  parameters,  so  we 
apply  it  to  the  null  list  <>.  We  furthermore  apply  it  to  the  initial  procedure  continuation  yg. 

This  initial  procedure  continuation  contains  an  initial  entry  0g  for  the  leave  component  which 
defines  a  null  continuation  for  the  procedure.  The  other  two  entries  are  ©.  Finally,  the 
procedure  abstraction  is  applied  to  the  store  ctj  to  obtain  the  program  answer. 
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5.0  Conclusion 

Two  sets  of  observations  come  to  mind  w  hen  considering  the  foregoing  definition,  one  concerning 
denotational  semantics  in  general  and  one  concerning  the  semantics  of  AMDL. 

Looking  first  at  the  issue  of  denotational  semantics,  w-e  see  how  denotational  semantics  has  been 
able  to  precisely  describe  even  the  most  complex  and  tedious  details  of  AMDL.  Furthermore,  it 
has  done  so  without  reverting  to  an  operational  model  where  unwanted  objects  such  as  registers 
and  stacks  enter  in.  On  the  negative  side,  the  use  of  Greek  characters  and  short  function  names 
greatly  reduces  the  readability  of  the  definition  at  first  glance.  I  say  "first  glance."  because  after 
working  with  the  equations  for  a  long  period  of  time  the  reduction  in  the  size  of  the  terms 
resulting  from  these  conventions  seems  more  important  in  relation  to  having  mnemonic  variables 
names.  Another  problem  arises  in  the  use  of  nontrivial  data  structures,  such  as  we  saw  with  the 
environment.  References  such  as  6^311  are  not  easily  processed  by  the  human  reader.  The 
solutions  to  both  of  these  problems  are  obvious,  one  simply  uses  mnemonic  variable  names  and 
record  structures  with  mnemonic  selectors.  The  notation  used  in  this  definition  is  similar  to  the 
that  used  originally  in  [Milne  and  Strachey], 

Several  things  that  can  also  be  said  concerning  the  semantics  of  AMDL.  First  of  all.  there  are 
several,  rather  difficult  semantic  concepts  in  AMDL.  most  notably 

°  Overlays 

°  Leave.  Restart  and  Resume 

°  Use  of  same  identifier  for  structure  and  procedure 

No  matter  how  the  semantics  of  the  above  features  is  determined,  it  is  likely  to  be  extremely 
difficult  to  understand. 

Another  problem,  referred  to  earlier,  is  whether  or  not  to  explicitly  specify  the  order  of  ev  aluation 
of  constructs.  This  problem  arises  due  to  the  possibility  of  side-effects  in  AMDL  expressions  and. 
in  the  case  of  a  transfer,  the  possibility  of  nondisjoint  variables. 

The  question  of  run-time  errors  in  a  program  should  also  be  examined.  The  current  procedure 
simply  says  that  the  first  error  encountered  in  program  evaluation  results  in  an  immediate 
termination  of  the  program.  A  method  of  error  recovery  might  be  desirable  which,  of  course, 
should  be  rigorously  defined. 

Finally,  it  must  be  mentioned  again  that  parallelism,  a  fundamental  feature  of  any  HDL.  has  been 
totally  ignored  in  this  definition.  The  addition  of  this  feature  to  the  definition  will  have  a 
significant  effect.  Questions  of  shared  variables,  synchronization  and  process  termination  will 
have  to  be  examined.  This  undoubtedly  will  increase  any  conceptual  difficulties  that  currently 
exist. 

All  things  considered,  however,  one  must  be  encouraged  about  the  problem  of  precisely 
specifying  language  semantics  and.  in  particular,  the  semantics  of  HDLs.  Hopefully,  this 
definition  will  work  as  a  catalyst  for  further  efforts  in  this  area. 
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6.0  Appendix 

6. 1  Syntactic  Domains 


A:  Act  Actions 

B:Bin  Binary  Operators 

X:Con  Constants 

Z:Dcl  Decode  Clauses 

A:  Dec  Declarations 

E:Exp  Expressions 

I:lde  Identifiers 

N:Num  Numerals 

P:Ref  Variable  References 

K.SRf  Structure  References 

2:Str  Structures 

T:Tra  Transfer  Operators 

T:Una  Unary  Operators 

ri:Var  Variables 


57 


6.2  Syntactic  Equations 


A::=  (cond  (E  A))  |  (decode  E  Z 2  Z->  ...  Zn)  |  (label  I  A)  |  (leave  I)  | 
(restart  I)  |  (resume  I)  |  (repeat  A)  |  (seq  Aj  A2  ...  An)  | 

(par  A 2  A2  ...  An)  |  (call  I  Ej  E2  ...  En>o)  I  E  I  (write  E) 

B::=  usplus  |  usdifference  |  ustimes  |  usquotient  |  usremainder  | 
useql  |  usneq  |  uslss  |  usgtr  |  usleq  |  usgeq  |  ustst  | 
tcplus  |  tcdifference  |  tctimes  |  tcquotient  |  tcremainder  | 
tceql  |  tcneq  |  tclss  |  tcgtr  |  tcleq  |  tcgeq  |  tctst  | 
ussrO  |  ussrl  |  ussrr  |  ussrd  |  usslO  |  ussll  |  usslr  |  ussld  | 
usor  |  usxor  |  usand  |  useqv  | 
usconc 

X::=  (bconst  N-j  N2)  |  (hconst  N1  N2)  |  (oconst  N1  N2)  |  N 

Z  ::  =  ((2j  22  ...  2n)  A)  |  (2  A)  |  A  |  (otherwise  A) 

A::=  (proc  nQ  (PIj  n2  ...  nn>0)  Aj  A2  ...  Am>0  A)  | 

(over  n0  (112  n2  ...  nn»  |  n 

E  ::  =  (ussub  E  K)  |  (B  E2  E2)  |  (T  E)  |  (call  P  Ej  E2  ...  En>0)  | 

(T  (?l  P2  ...  Pn)  E))  |  P  |  X 

1  ::  =  The  set  of  legal  identifiers 

N  ::  =  The  set  of  numerals  consisting  of  the  digits  0-9 

P::=  (words  (bits  1  K)  E)  |  (words  I  E)  |  (bits  1  K)  |  1 

K::=  (pair  Xj  X2)  |  E 

2  ::=  (pair  Xj  X2)  |  X 

T  usset  |  tcset 

T::=  tcminus  |  usnot 

n  ::=  (words  (bits  I  2j)  22)  |  (words  I  2)  |  (bits  I  2)  |  I 
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6.3  S emam  ic  Domains 


v:V  =  {0.1}  Bits 

/?:B  =  V+  Bit  Strings 

e:E  =  {<m,n>|m,n€N.  n>0,  0<m<2n-l}  Expression  Values 


t:T  =  {true, false} 
m,n:N  =  {0,1,2,...} 

z:Z  =  {..., -2,-1, 0,1,2,...} 

p:P  =  NXN 
0  =  {©} 

ERR  =  N 
OUT  =  N 

ANS  =  (ERR  +  OUT)* 


Booleans 

Non-negative  Integers 

Integers 

Pairs  of  N 

Set  consisting  of  the  "undeclared"  element 
Error  codes 

Output  from  write  action 
Final  answers 


a:S  =  L— (V  +  F+  0) 

u:W  =  L  + 
a:A  =  W  + 

w:WORD  =  WXP 
a:ARRAY  =  AXPXP 

0:C  =  S— ANS 


Stores 

Word  Location  Strings 
Array  Location  Strings 

Word  Variable  Descriptors 
Array  Variable  Descriptors 

Action  Continuations 


k:K  =  E— C 


Expression  Continuations 


jt:M  =  P— »C 

tj.H  =  W-»C 

o:0=  A  —  ANS 

X:X  =  Q-U-C 

y:G  =  L— >((JX(J  +  0)X(J 

^:Y  =  E— ANS 

j:J  =  C 


Structure  Reference  Continuations 

Variable  Reference  Continuations 

Overlay  Continuations 
Declaration  Continuations 
+  0))  +  0)  Procedure  Abstraction  Continuations 
Binary  Operator  Continuations 

Jumps 


f:F  =  E*-G-C 


Procedure  Abstractions 


q:Q  =  lde-»({true}  +  0) 


Local  Binding  Functions 


p:U  =  UVARXUPROCXULABXL  Environments 
UVAR  =  (Ide— (ARRAY  +  WORD  +  0)) 

UPROC  =  (lde-*((LXN)  +  0)) 

ULAB  =  (lde-»((JXJ)  +  0)) 


8:D  =  All  finite  domains  which  can  be  constructed  from  given  primitive  domains  and  a 
finite  number  of  construction  operations 
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6.4  Semantic  Functions 


6.4.1  Actions  (A:Act-*U-»G-*C-»C) 


(Al)  A[(cond  (E  A))]pY0  =  £[E]pY{\e.e41  *O-»A[A]pY0 , 

6} 

(A2)  ^[(decode  E  (Zj  Z2  ...  Zn))]pY0  = 

E[E]pY{Ae.Z[Z1](ei1)(0){Z[Z2](el1)(1)  ... 

{Z[Zn](ein)(n-1){err(16)}pY0}  ...  py6)py6} 

(A3)  A[(label  I  A)]pY0  = 

A[A]updafe(p,3,pi3[<0.A[(label  I  A)]pytf >/I])y^ 

(A4)  A[(leave  I)]pY0  = 

pl3[I]£0—p43[I]-H, 

5€0-*err(7), 

Y(64-1)€0-»err(8), 
y(541)i1 
where  6  =  p42tl] 

(A5)  ^[(restart  I)]pY0  = 

pi3[I]€0— p!3[I]i2, 

6£0->err(  7), 

Y(641)£0-*err(8). 
y(64-  1)4-2 
where  6  =  p42[I] 

(A6)  ^[(resume  I)]pY0  = 

5£0-»err(7), 

Y(6A1)£0-*e/,r(8), 

Y(6  4 1 )  1 3£  0  -»  err{8), 

Y(5 1 1)4-3 
where  6  =  p4>2[I] 

(A7)  ^[(repeat  A)]pY0  = 

4[A]pY{A[(repeat  A )]py0} 

(A8)  A[(seq  Aj  A2  ...  An)]pY0  = 

^[Aj]pY{A[A2]pY  ...  {A[An]pY0}  ...  } 


(A9)  A[(par  A1  A2  ...  An)]pY0  = 

^[Ai]pY{A[A2]pY  ...  {A[An]pY^}  ...  } 

(A10)  A[(call  1  Ej  E2  ...  En>g)]pY^aj  = 
6£0-»err2(9). 


W 
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St2#n-»er/-2(10) , 

->(Y(5i1)€0)-*err2(17), 

.£[E2]p7{Xe2-  f[EnJpy 

{Xen<Ti(6A1)(ei.e2 . en)Yi)  )}ffi 

where  6  =  pi2(I) 

\  =  0 

n  is  the  subscript  of  En 
Yj  =  7[upda(e(Y(p'l'4).3,j)/p'l’4][<j.©.®>/6l1] 
if  n  =  0.  then  the  last  clause  in  the  equation  reduces  to 
<t(S4.1)(<>)yj 

(All)  A[E]pY0  =  £[E]py{Ae.0} 

(A12)  A[(write  E)]py#  =  £[E]pY{\e<r.#(<j)§<e±1  in  OUT>} 

6 .4.2  Binary  Operators  (B:Bin— »(EXE)— ►Y-»ANS) 

(Bl)  B[usplus](e-|  .e^  =  «/'(<e1l1  +  e2±1  ,m  + 1  >) 
where  m  =  max(e1 42,e2±2) 

(B2)  S[usdifference](e1,e2)i/' =  ^(enormlei-n  -e2±1,m  +  1)) 
where  m  =  max(e- (  l2.e2A2) 

(B3)  Btustimes](e-|,e2)</'  =  </'(<e-|i1  *e2-H,eiA2  +  e-|4.2>) 

(B4)  B[usquotient](ei.e2)</' = 
e2i1  =  0-»e/r(15), 

4'(K6^4'1/  62'1'1  ,6-j 

(B5)  B[usremainder](e1  .e2)i/- = 
e2A1  =  0-*err(15). 

»^(<e-j  4. 1  mod  e2l1.e2l1>) 

(B6)  B[useql](e1  ,e2)\f  =  ^(<(e-|  il  «e2*1-»1,0),1>) 

(B7)  8[usneq](ei,e2)^  =  i/'(<(e1il5te2ll-M,0),1>) 

(B8)  B[uslss](e1  ,e2)+  =  4'(<(e1  II  >e2i1  —  0.1),1  >) 

(B9)  8[usgtr]le1.e2W  =  «M<(e1il<e2il-*0,1),1>) 

(BIO)  Stusleq](eve2)^  =  v/'(<(e1l1<e24.1  —  1,0),1>) 

(Bl  1 )  B[usgeq](e-,.e2)i/'  =  <M<(ei41>e2i1-»1,0),1>) 

(B12)  B[ustst](e1  ,e2W  =  W^e-,  il  =  e2*  1  -»1  .e,  il  <e2i0-»1,2),2>) 

(B13)  B[tcplus](e-|  .e2)if  =  i(<  fcexffe^mjll  +  /cexf(e2,m)i1,m  +  1>) 
where  m  =  max(e- 1 i2,e2i2) 

(B14)  B[tcdifference](ei,e2)4'  =  ^(enorm((cex/(e1  ,m)(1  -  fcexf(e2,m)i1  ,m  +  1)) 
where  m  =  max(e1 12,e2l2) 

(B15)  B[tctimes](e1,e2)i|'  =  4'(enorm(fcva((e1)*(cva/(e2),e142  +  e2i2)) 

(B16)  B[tcquotient](ei.e2)<£  = 

e2i1  =  0-*err(15), 
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^(enormitcvaHe^  )/fcva/(e2).e1 42)) 

(B17)  8[tcremainder](e-|  e2H  = 
e2i1  =0-»err(l5), 

i(enorm(tcval(ei)  mod  fcva/(e2).e242)) 

(B18)  8[tceql](e1.e2)i|'  =  ^(<(fcva/(e-|)  =  fcva/(e2)-*1.0).1>) 

(B19)  B[\cneq](eve2)>P  =  H<ltcvaHei)*tcval(e2)—lO).1>) 

(B20)  B[tclss](ei.e2)^  =  ^(<(fcva/(e1)>fcva/(e2)-*0,l).l  >) 

(B21)  S[tcgtr](e1.e2)i/-  =  «H<(fcva/(e-,)<fcva/(e2)-* 0.1). 1  >) 

(B22)  Sttcleqlfe^e^i/-  =  >/'(<(/cva/(e1)<rcva/(e2)->1.0).1>) 

(B23)  B[tcgeqj(e.,.e2)>/<  =  ^(<(fcva/(e1)>fcv^a/(e2)— 1,0). 1>) 

(B24)  8[tctst](e1.e2)i  = 

V'(<(fcva/(e1)  =  tcval(e2)-*'\,tcval{e-\)<tcval(e2)-*0.2),2>) 

(B25)  8[ussr0](e1,e2)</' = 

e241>ei4.2— ^(<0,e14.2>), 

>/'(econv(pivr(e2i1 ,0)§ex/racf«1  .e-,  42  -  e24 1  >,/3))) 
where/?  =  bconvi,e^) 

(B26)  8[ussr1](e1.e2)i/' = 

e241  >ei  42-*>/.(econv(pwr(ei  42.1 ))), 

«/'(ecomr(pwr(e241 ,1  )§exfracf(<1  ,e-|  42  -  e24 1  >./?))) 
where  /?  =  bconv(e^) 

(B27)  8[ussrr](e1.e2)>/' = 

n  =  0— ^(e,), 

>/'(econ\r(exfracf(<e1 42  -  n  +  1  ,e7  42>./?)§exfracf(<  1  .e,  42  -  n  >,/?))) 
where  n  =  e241  mode142 
/?  =  bconv(ei) 

(B28)  8[ussrd](e-|.e2)i// = 

e241  >e1 42  -*i^(econv(p»vr(e1 42, /?4 1 ))), 

</'(econv'(pivr(e241  ,/341)§exfracf(<1  .e-,  42  -  e24 1  >,/?))) 
where  /3  =  bconv{e j) 

(B29)  8[ussl0](e1,e2)*  = 

e241>e142—^(<0,ei42>), 

'Heconv(extract(<e2i'\  +  1,e142>,/S)§pwr(e241.0))) 
where  /?  =  bconv[e^) 

(B30)  8[ussl1](e1.e2)>/'  = 

e241>e1 42-*>//(econv(pwr(ei42,1))), 

+{econv{extract(<e2l‘\  +  1,e142>,/?)§pwr(e241,1))) 
where /?  =  bconv^e^ 

(B31)  8[usslr](e1  e2)^  = 
n  =  0-*i/'(e1), 

+(econv(extract(<n  +  1,e142>,/?)§exfracf(<1,n>,/3))) 
where  n  =  e24 1  mod  1 42 


0  =  bconv(e^) 

(B32)  e[ussld](ei,e2)'// = 

e23 1  >e-,  i2-»econv(pwr(e-|  32,/33(e-|  32))), 
econv(extract(<e2i  1  +  1  ,e1 32>./?)§pwr(e231  ,/S  4-  (e1  32))) 
where  0  =  bconv(e- 1) 

(B33)  B[usor](ei,e2)^  =  \p(econv(0)) 
where  /S3i  =  or(ad)usf(toconv(ei).m,0)3i,ad/usf(bconv(e2),m,0)3i) 
ft  0  =  m  =  max(e1 32,e232) 
where  or:(VXV)-»V 

or(v1  ,v2)  =  (v1  +  v2>  1  -*•  1 ,0) 

(B34)  B[usxor](e-|  ,e2)\p  =  4'(econv(0)) 
where  >3  3  i  =  xor(adjust(bconv(e^).m,0)i\,adjust(bconv(e2).m,0)i\) 
tt  0  =  m  =  max(e-|32,e232) 
xor.(VXV)— *V 

xor(v1  ,v2)  =  (v1  +  v2  =  1  -*■  1 ,0) 

(B35)  B[usand](e-|  ,e2)</'  =  \p(econv(0)) 
where  0i\  =  and(adjust(bconv(e^),m,0)i\.adjust(bconv(e2),m,0)ii) 
#0  =  rr\  =  max(e1 32,e232) 
and:(VXV)-»V 
and(v1,v2)  =  (v1*v2) 

(B36)  B[useqv](e1,e2)v/'  =  4'(sconv(0)) 
where  >33  i  =  eqv(adjust(bconv(e^).m.0)i\,adjust(bconv(e2),m,0)i\) 
tt  0  =  m  =  max(e1 32, fc232) 
eqv.(VXV)— V 
eqv(v-)  ,v2)  =  (v-j  +v2*2-»1.0) 

(B37)  B[usconc](e1,e2)>|'  =  |(econv(bconv(e1)§faconv(e2))) 

6 .4.5  Constants  (C:Con-»E) 

(Cl)  C[(bconst  N-|  N2)]  =  <W[N1]./V[N2]> 

(C2)  C[(hconst  N2)]  =  <A/[N’1],W[N2]> 

(C3)  C[(oconst  N -j  N2)]  =  <W[N1],A/[N2]> 

6.4.4  Decode  Clauses  (Z:Dcl— >N-»N-+C— >U— >G— »C) 

(Zl)  Z[«2j  S2  -  2n)  A)]nm0lPY02  = 

(S[21]31<n<S[21]32)V(S[22]3l<n<S[22]32)V  ...  V 
(S[2n]3l<n<S[2n]32)-A[A]pY<?2  . 

(LI)  Z[(Z  A)]nm^1py^2  = 

S[2]31<n<S[Z]32-A[A]py02 


63 


(Z3)  Z[\\r\md\py02  = 

n  =  m-»A[A]py02 

*\ 

(Z4)  Z[(otherwise  A)]nm0=A[A] 

6.4.5  Declarations  (D:Dec-»X-»X.  DP:Dec-*U-»C-*C) 

(Di)  o[(proc  n0  (n:  n2  ...  nn)  a2  a2  ...  Am  aj]x  = 

P[nO](1){Xqp0.x(q)(updafe(p,2,p42[<l,n>/P/[no]]))a[O/l]} 
where  n  is  the  subscript  in  nn 
I  =  new(o) 

(D2)  D[(over  n0  (r^  n2  ...  nn))]x  = 

p[n0](2){Xqpa.PO[n1]np{PO[n2]np  ...  { PO[nn]npo }  ...  }<>} 
where  o  =  {Xa.  U  (a41)*  size(8i2)-*err2(6), 
xqpi®) 

n  =  (6£ARRAY-»s/'ze(xA3), 

1) 

S  =p41(P/[n0]) 

P\  =  updafe(p,1,p4l[updafe(6,1.(5€ARRAY-*’a.a41))/P/[n0]]) 
(D3)  D[n]=P[n](0) 

(DPI)  op[(proc  n0  (nj  n2  ...  nn)  Aj  a2  ...  Am  A)]pxtf x  = 

p[ni]o{p[n2]o  ...  {^[nnjoxi}}q-|Pi^i 
where  q.,=M.© 

Xl  =  {C)[A1]{0[A2]  {D[Am]X2}}} 

X2={Xq2P2DP[Ai]0P2{DP[A2]0P2  ...  {DP[Am]Op202}}} 

02  =  {\sj.0j(aj[f/l])} 

l  =  p42(P/[n0])41 

f  =  X(e1,e2 . en^2'xl°x2°  -  °xnotf3 

03  =  A[A]p3y2[updare(Y(|),2,03)/|]{y(l)41} 

Xj  =  sefba(p41(P/[nj])i.l,ej) 

P3  =  opdafe(pj.4.l) 

(DP2)  DP[(over  nQ  (nx  n2  ...  nn))]p0  =  0 
(DP3)  DP[no]p0  =  0 


6.4.6  Expressions  (£:Exp-»U-»G— ►«— >C) 

(F.l)  £[(ussub  E  K)]pyx  = 

E[E]py{Xe.fc[K]p7p} 

where  p  =  {Ap.pil  >pl2-»<c(econv(exfracf(nomj(p,<n  -  1 ,0>),/9))), 

err(  14)}, 

n  =  max(pil  +  1,e±2) 

/?  =  adjust(bconv(e),o,0) 

(E2)  £[(B  Ej  E2)]PYk  = 

F[El]PY{^ei.E[E2]pY{Xe1<T.8[B](e1.e2){\e.«(e)(T}}} 

(E3)  £[(T  E)]pyx  = 

f[E]pY{Ae.K(U[T](e))}} 

(E4)  £[(call  P  Ej  E2  ...  En>Q)]py(«Tj  = 

S€0-»err2(  9), 

S-f2*n-»err2(10), 

y(6il)€0-»err2(17), 

EfElJprtXej  .£[E2]py{Ae2  r[E n]py 

{Aen.a1(6.H)(e1.e2 . en)Yj}  ...  }}CTl 

where  <5  =  p!2(fl/[pj) 

y1  =  y[upda(e(y(pA4),3,j)/p44][<j.©,®>/5il] 
j  =  8[P]py{Awa2.»c(deref(«.CT-)))o->} 
n  is  the  subscript  of  En 

if  n  =  0.  then  the  last  clause  in  the  equation  reduces  to 

ff(6*1)(<>)Yl 

(E5)  £[((P j  Pi  ...  Pn)  T  E))]pyx  = 

£[E]py{Ae.8[P1]py{Aw1.fl[P2]py{Aw2.  ...  P[Pn]pyr,  ...  }}} 
Where  tj  =  {Awnff.»ce(r[T]((u1§w2§  ...  §«n),e)a)} 

(E6)  £[P]pyx  =  8[P]py{A«a.K(de/’eftw.ff))a} 

(E7)  £[X]pyx  =  k(C[X]) 

6.4. 7  Identifiers 

6.4.8  Numbers  (N:Num-»N) 

6.4.9  Programs  (PROG :Dec-*ANS) 

(PROG1)  PPOG[A]  = 

n*0-*err2(20), 

D[A]{Aqp.OP[A]ptf}q0po<To 
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where  A  =  (proc  nQ  (nx  n2  ...  nn)  A:  A2  ...  Am  A) 
n  is  the  subscript  in  nn 

q0  =  {\I.e> 

P0  =  <{XI.©},{XI.©},{XI.©},©> 
a0  =  {X|.©} 

0  =  {Xa1.a1(l1)(<>)71CT1} 

I1=(pi2[n0])*1 

Yl  =  yo[<^O-®,0>/ll] 

TO  =  {XI.©} 

<?0  =  {Xa.<>} 

6.4.10  Variable  References  (fl:Ref-»U-»G->H->-C1  fl/:Ref-*lde) 


(Rl)  fl[(words  (bits  I  K)  E)]py7j  = 

ARRAY-*err(1 1). 

£[E]py{Xe.-Wega/(<e41,e41>\S4.3)-»e/T(12), 

K[K]pyp} 

where  «  =  P*1[I] 

H  =  {Xp.->/ega/(p,S42)->err(13)l 

i](extract(norm(p,Si2).u))} 
where  w  =  ex//-act(nom7(<eJ.1,e41  >,643), 611)41 

(R2)  ft[(words  I  E)]py7j  = 

6$ARRAY— err(11). 

F[E]py{Xe.-'/ega/(<e41,e4-1>,54.3)->'err(12), 

ij(exfracf(norm(<e4l,e41>\S43),S41)41)} 

where  S  =  PU[l] 

(R3)  fl[(bits  I  K)]py7j  = 

6CWORD— err(11), 

K[K]py{Xp.-i/ega/(p,54.2)-*err(13), 

r)(ext  /•acf(norm(p,S42).8  4  1 ))} 

where  5  =  p*1[I] 

(R4)  fl[l]pyT|  = 

8€WORD-*err(11), 

i}(841) 

where  6  =  pl1[I] 

(RI1)  ft/[(words  (bits  I  K)  E)]  =  I 


(RI2)  R/[(words  I  E)]  =  I 
(R13)  R/[( bits  I  K)]  =  I 
(RI4)  ft/[I]  =  I 
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6.4.11  Structure  References  (K:SRf-»U-»G-*M-»C) 


(Kl)  K[(pair  Xj  X2)]PYM  » |x(C[X j] 4- 1  -C[X2] 4- 1 ) 

(K2)  ^[E]p7jx  =  £'[E]pT'{\e.fjL(e4’1.e4’1)} 

6.4.12  Structures  (S:Str — ►  P) 

(51)  S[(pair  X]  X2)]-<C[X1]*1,C[X2)41> 

(52)  S[X]  =  <C[X]i1,C[X]l1> 

6.4.13  Transfer  Operators  (T:Tra— *(WXE)-»S— >S) 

(Tl)  r[usset](w.e)  =  setba(u>,bconv(e )) 

(T2)  r[fcse/](w,e)  =  setb(u, adjust^,  44  «,1)) 
where  [3  =  bconv(e) 

6.4.14  Variables  (P:Var-*N->X-‘X,  PO:Var—  N-*U— O— O) 

(PI)  P[(words  (bits  I  2j)  22)]nxqp<ri  = 
q[I]  =  true-*err2(2)<r, 

xq[true/I]updafe(upda/e(p,1,p;i[<a,S[21],S[22]>/I]),2,p4.2[©/I])CT 
where  a  =  (n  =  2-k®,resbape(s/ze(S[2j])1a))) 
a2  =  (n  =  2— j,setba(w,<0>)aj) 
w  =  gef(m,oj) 

m  =  s/ze(S[2j])*s/ze(S[22]) 

(P2)  P[(words  I  2)]nxqp  =  err(3) 

(P3)  P[(bits  I  ZJJnxqpa^ 

q[I]  =  true-»err(2)<r, 

xq[true/I]upda/e(upda/e(pt1,pl1[<w,S[Z]>/I]),2,p>1.2[©/I])ff2 
where  u  =  (n  =  2-*’®,gef(n1.<Tj)) 

cr2  =  (n  =  2-»«j^,sefba(w,<0>)a^) 
n-,  =  s/ze(S[S]) 

(P4)  P[I]nXPP  = 

q[I]  =  true-*e/r(2), 
n*1-*err(3), 

xq[true/I]updafe(upda/e(p,1,pi1[©/I]jrt2,pi2[®/I]) 

(POl)  PO[(words  (bits  I  Zj)  Z2)]npoa  = 

S€ARRAY-»err2(5), 

-«(/ega/(S[Z1],5i2)A/ega/(S[Z2],5i3))-e/'r2(5), 
(s/ze(S[Zj])*s/ze(StZ2])  mod  n)*0-»err2(6), 
o(aconc(a,reshape(n, Wpufwpn  +  1§  ...  §wp;2))) 


where  6  =  pi1[l] 

Uj  =  exfrac»(norm(StZ1],5i2),filHi) 
p  =  no/-/n(S[Z2].5J'3) 

(P02)  PO[(words  I  Z)]npoa  = 

6  £  ARR  A  Y-*  err2(5) , 

->/ega/(S[Z],Si3)-»err2(5), 

(s/ze(54-2)*s/ze(S[2])  mod  n)*0-»err2(6), 
o(aconc(a,res/jape(nlupi1§upi1  +  1§  ...  §wpi2))) 
where  5  =  p!1[I] 
coj  =  541  li 

p  =  norm(S[Z],6i3) 

(P03)  PO[(bits  I  Z)]npoa  = 

S€0-*err2(5), 

-i  lega/(S[Z]  ,6  i  2)  -»  err2(  5) , 

(SewORD— 

(s/ze(S[Z])  mod  n)~0-»err2(6), 
o(aconc(a,reshape(n,exffacf(norm(S[2],6t2),6l1)))) 
8€ARRAY— 

(s/'ze(S[Z])*s/ze(6T3)  mod  n)*0-»e/Y2(6), 
o(aconc(a,resbape(n,Wp;i§wpi1  +  i§  ...  §wpi2))) 
where  «  =  P*1[I] 

Wj  =  exf/acf(norm(S[Z],5T2),8iHi) 
p  =  nomj(Si3,543)  =  <1,s/ze(6i3)> 

(P04)  PO[I]npoa  = 

6£0—err2(  5), 

-« legal(S  [2]  ,6  42)  -*  er  r2(5), 

6CWORD— 

(size(542)  mod  n)*0-»err2(6), 
o(aconc(a,reshape(  n,5t1 ))) 

8£ARRAY-» 

(s/ze(842)*s/ze(6;3)  mod  n)*0— err2(6), 
o(aconc(a,reshape(n,wp|1  §wp|1  +  1  §  ...  §«pi2))) 
where  S  =  pi1[I] 

Wj  =  84l4i 

p=  norm(S43,543)  =  <1,size(6l3)> 
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6.5  Support  Functions 


(SF1)  abs:Z-*N  Absolute  value 

abs(z)  = 
z>0-*z, 

-z 

(SF2)  aconc:(AXA)-»A  Row  concatenation  of  two  As 

aconc(a},a2)  = 

<ail1§a2't1,a2'f2§a2A2,  ...  ,a|4(#aj)§a2'M#a2)> 
for  #  a\  =  tfaj 

(SF3)  ad/us/:(BXNXV)— *B  Shortens  a  bitstring,  or  extends  it  on  the 

left  with  copies  of  a  given  element  from  V 

adjust^ 8,n,v)  = 

n<  # P~* extracts  # $-  n  +  1, #/?>,/?), 
pwrin-#/3,\i)§p 

(SF4)  6comr:E-+B  Converts  an  E  to  a  B 

bconv{e)  =  l 3 
such  that  econv(fi)  =  e 

(SF4.1)  deref:(WXS)-»E  Dereference  function 

deref(u.o)  = 

econvf<a(wil),<r(w42) .  a(u4(#w))>) 

for  #w>1.  cr(«4i)€V,  i  =  1 ,2 . 


(SF5)  econtr:B-*E  Converts  a  B  to  an  E 

econv{j 3)  =  <n  ,#/i> 
where  n  =  (# ft  =  l-»/34l, 

/H(#)3)  +  2*(e41)) 
e  =  econv{extract(<  1 ,  #  /?  -  1  > ,  #  /?)) 


(SF6)  enorm:(ZXN)-»E 
enorm(z,n)  = 

z>0-»<z  mod  2n,n>, 
enorm(2n  +  z,n) 
for  n>1 

(SF7)  errN—S—ANS 

err(n)o  =  <n  in  ERR> 

(SF7a)  err2:N-»ANS 

err2(n)  =  <n  in  ERR> 

(SF8)  exfracf:(PXD  +  )-»D + 
exfracf(p,6)  = 


Normalizes  <Z,N>  to  an  E 


Program  Error 


Program  Error 

Returns  subsequence  of  member  of  D  + 
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<54(p41),S4((p41)  +  1) . S4(p42)> 

for  1<p41<pl2<  #6 

(SF9)  ge/:(NXS)-»L  Gets  locations  from  an  S 

gef(n,«r)  = 

n  =  1-+<new(ff)>, 

<neiv(a)>§gef(n-1,<T[0/ne»v(<T)]) 
for  n>1 

(SF10)  /ega/:(PXP)-»T  Determines  if  access  is  legal 

legal(  pvp2)  = 

P241<P242-*(P241<PiI1  <Pi42<p242), 
(P241>Pi41>Pi42>P242) 

(SF11)  max:(NXN)-»N  Maximum 

max(n1.n2)  = 
n1  <n2-*n2, 

n1 

(SF12)  neiv:S-»L  Gets  a  sequence  of  locations  from  an 

new{o)  = 

I  such  that  <j(I)  =  © 

(SF13)  norm\( PXP)-»P  Normalizes  access 

norm(p1  ,p2)  = 

P241  <p242— »<p-j  41  -  p24 1  +  1,p^42  —  p24 1  +  1), 

<p241  -  Pi  41  +  1,p241  -  p1 42+  1  > 
for  fega/(pvp2) 

(SF14)  ptvr(NXV)-»B  Generates  tuples  of  an  S 

pwr(n,v)  =  <vvv2 . vn> 

where  vj  =  v,  i  =  {1 ,2,  ...  ,n} 
for  n>1 

(SF15)  ravel. k~*W  Concatenates  rows  of  A 

ravel(a)  =  a41§a4l§  ...  §a4(#a) 

(SF16)  res/>ape:(NXW)-+A  Reshapes  a  W  into  an  A 

reshape(  n,«)  = 

<<a41,a42 . a4m>, 

<u4(m  +  1),u4(m  +  1) . w4(2*m)>, 


<u4((n-1)*m  +  1),w4((n-1)*m  +  2) . w4(n*m)» 

where  m  =  (#u)/n 

for  n>1  and  (#«  mod  n)  =  0 
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(SF17)  sefb:(WXB)-*S-»S  Updates  S  with  a  B 

setb(u,p)o  =  o[fiU/ol-\][pi2/ul2\  ...  [0in/wln] 
for  #  u  =  it  p 

(SF18)  sefba:(WXB)-»S-»S  Updates  S  with  adjusted  B 

sefba(w,/J)  =  setb(u,adjust(i S,  #  u.O)) 

(SF19)  s/'ze:P-»N  Gives  "size"  of  a  P 

.  s/ze(p)  =  abs(p!1  -  p!2)  +  1 

(SF20)  fcexf:(EXN)-»N  Extends  E  and  returns  "value"  part 

fcexf'e.n)  =  econv(ad/usf(/?,n,/?11))11 
where  ft  =  bconv(e) 
for  n>1 

(SF21)  tcval:E->Z  Two’s  complement  interpretation  of  E 

tcval(e)  = 

e4.1>2n-1—eA1  -  2n, 
ell 

where  n  =  e!2 

(SF22)  update:(D +  XNXD)-»D +  Uist  update  function 

update(8,  n,d)  = 

<511,512 . 61(n-1),d,5l(n  +  1),  ...  51(#S)> 

for  1<n<#6 


6.6  Error  Codes 


1)  Program  defined  with  formal  parameters 

2)  Multiply  defined  identifier 

3)  Variable  declared  without  bit  structure 

4)  Undefined  variable  reference  in  overlay 

5)  Illegal  word  or  array  reference  in  overlay 

6)  Variable  reference  does  not  map  evenly  in  overlay 

7)  leave,  restart  or  resume  of  undefined  procedure  or  label 

8)  leave,  restart  or  resume  of  inactive  procedure 

9)  Reference  to  undefined  procedure 

10)  Number  of  actual  parameters  does  not  match  number  of  formal  parameters  in  procedure  call 

11)  Undefined  or  improper  variable  reference 

12)  Illegal  word  specified  in  array  reference 

13)  Illegal  bit  sequence  specified  in  word  reference 

14)  Illegal  bit  sequence  specified  in  ussub  expression 

15)  Division  by  ?.ero 

16)  Unsatisfied  decode 

17)  Recursive  procedure  call 
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